{"id":20950253,"url":"https://github.com/ghalactic/github-release-from-tag","last_synced_at":"2025-05-14T03:32:34.103Z","repository":{"id":50559611,"uuid":"349258024","full_name":"ghalactic/github-release-from-tag","owner":"ghalactic","description":"A GitHub Action that creates GitHub Releases from your Git tags","archived":false,"fork":false,"pushed_at":"2024-10-30T04:55:06.000Z","size":10451,"stargazers_count":33,"open_issues_count":2,"forks_count":3,"subscribers_count":3,"default_branch":"main","last_synced_at":"2024-10-30T07:29:15.723Z","etag":null,"topics":["actions","github-actions","publishing","release","release-automation"],"latest_commit_sha":null,"homepage":"https://github.com/marketplace/actions/github-release-from-tag","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ghalactic.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-03-19T00:46:12.000Z","updated_at":"2024-10-30T04:55:09.000Z","dependencies_parsed_at":"2024-11-07T07:40:57.249Z","dependency_job_id":null,"html_url":"https://github.com/ghalactic/github-release-from-tag","commit_stats":{"total_commits":766,"total_committers":5,"mean_commits":153.2,"dds":0.5913838120104439,"last_synced_commit":"a2b32d776f88611e3b5e3c3a85525a5a92459942"},"previous_names":["ghalactic/github-release-from-tag","eloquent/github-release-action"],"tags_count":51,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ghalactic%2Fgithub-release-from-tag","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ghalactic%2Fgithub-release-from-tag/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ghalactic%2Fgithub-release-from-tag/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ghalactic%2Fgithub-release-from-tag/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ghalactic","download_url":"https://codeload.github.com/ghalactic/github-release-from-tag/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":225275708,"owners_count":17448387,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["actions","github-actions","publishing","release","release-automation"],"created_at":"2024-11-19T00:47:33.644Z","updated_at":"2024-11-19T00:47:34.143Z","avatar_url":"https://github.com/ghalactic.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# GitHub Release from Tag\n\nA [GitHub Action] that creates [GitHub Releases] from your Git tags. Does what\nyou _probably wish_ GitHub would just do without the need to use GitHub Actions.\n\n[github action]: https://docs.github.com/actions\n[github releases]: https://docs.github.com/repositories/releasing-projects-on-github/about-releases\n\n\u003cpicture\u003e\n  \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"/assets/images/release-summary-dark.svg\"\u003e\n  \u003cimg alt=\"Example release job summary\" src=\"/assets/images/release-summary-light.svg#gh-light-mode-only\"\u003e\n\u003c/picture\u003e\n\n## Overview\n\nThis action creates releases by sourcing the release data from the place where\nit makes the most sense to keep it — your Git tags. By harnessing [SemVer] to\ndetermine pre-release status, and [Markdown] for formatting, your GitHub\nReleases become a natural extension of your Git tags.\n\n[semver]: https://semver.org/\n[markdown]: https://docs.github.com/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github\n\nIn addition, this action has been designed to feel like it _could_ be a\nfirst-party GitHub feature. Its feature set closely mirrors what you have access\nto when you [publish a GitHub Release manually].\n\n[publish a github release manually]: https://docs.github.com/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release\n\n## Features\n\n- [Minimal configuration, or often **zero** configuration](#configuration)\n- [SemVer stability determines **pre-release** status](#release-stability)\n- [**Markdown** support in tag annotation messages](#release-name-and-body)\n- [Asset uploading with support for **labels** and **checksums**](#release-assets)\n- [Automated **release notes** support](#automated-release-notes)\n- [Release **discussion** creation](#release-discussions)\n- [Releases can be created as **drafts**](#draft-releases)\n- [Creation of initial **🚀 reactions ❤️** to promote engagement](#reactions)\n- [Creation of **job summaries** for the Actions run summary page](#job-summaries)\n- [Works with GitHub Enterprise Server (GHES)](#github-enterprise-server-support)\n\n## Usage\n\n### Workflow for tag creation\n\nMost of the time you will want tag pushes to trigger release publishing:\n\n```yaml\n# .github/workflows/publish-release.yml\nname: Publish release\non:\n  push:\n    tags:\n      - \"*\"\njobs:\n  publish:\n    name: Publish release\n    runs-on: ubuntu-latest\n    permissions:\n      contents: write\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v3\n      - name: Publish release\n        uses: ghalactic/github-release-from-tag@v5\n```\n\nIt's also possible to use [`if` conditionals] to restrict the release publishing\nstep inside a multi-purpose workflow, so that it only runs on tag pushes:\n\n[`if` conditionals]: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsif\n\n```yaml\n- name: Publish release\n  uses: ghalactic/github-release-from-tag@v5\n  if: github.ref_type == 'tag'\n```\n\n### Workflow for manual runs\n\nYou may also want to be able to manually publish releases for a specific tag.\nThis allows you to remedy failed publish attempts, or publish tags that were\ncreated before automated release publishing was set up:\n\n```yaml\n# .github/workflows/publish-release-manual.yml\nname: Publish release (manual)\non:\n  workflow_dispatch:\n    inputs:\n      tag:\n        description: The tag to publish\n        required: true\njobs:\n  publish:\n    name: Publish release\n    runs-on: ubuntu-latest\n    permissions:\n      contents: write\n    steps:\n      - name: Checkout\n        uses: actions/checkout@v3\n        with:\n          ref: refs/tags/${{ inputs.tag }}\n      - name: Publish release\n        uses: ghalactic/github-release-from-tag@v5\n```\n\n### GitHub token\n\nBy default, this action uses [automatic token authentication] to obtain the\ntoken used to manage releases. If for some reason you want to supply a different\ntoken, you can do so via [action inputs]:\n\n[automatic token authentication]: https://docs.github.com/actions/security-guides/automatic-token-authentication\n[action inputs]: #action-inputs\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    token: ${{ secrets.CUSTOM_GITHUB_TOKEN }}\n```\n\nThe token requires the following permissions:\n\n- **Write** access to **repository contents**, in order to create releases.\n- **Write** access to **discussions**, in order to create [release discussions].\n\n[release discussions]: #release-discussions\n\nFor information on how to grant these permissions, see [Modifying the\npermissions for the `GITHUB_TOKEN`].\n\n[modifying the permissions for the `github_token`]: https://docs.github.com/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token\n\n\u003e [!NOTE]\n\u003e In February 2023, the default token permissions for new repos\n\u003e [changed to be read-only]. If your repo was created before this time, the\n\u003e default token would have been pre-configured with write access.\n\n[changed to be read-only]: https://github.blog/changelog/2023-02-02-github-actions-updating-the-default-github_token-permissions-to-read-only/\n\n### Release stability\n\nThis action uses [SemVer] rules to determine whether a tag should be published\nas a **pre-release**, or a **stable release**. The decision is made as follows:\n\n- If the tag name is a **\"stable\"** SemVer version, it's considered a **stable\n  release**.\n- If the tag name is an **\"unstable\"** SemVer version, it's considered a\n  **pre-release**.\n- If the tag name is **not** a valid SemVer version, it's considered a\n  **pre-release**.\n\n[semver]: https://semver.org/\n\nThe standard SemVer rules are relaxed a bit to allow for tag names with a `v`\nprefix (e.g. `v1.2.3`), as well as major/minor version tag names (e.g. `v1`,\n`v1.2`) as per [GitHub's recommendations for action versioning].\n\n[github's recommendations for action versioning]: https://github.com/actions/toolkit/blob/%40actions/core%401.1.0/docs/action-versioning.md#recommendations\n\nIt's also possible to [configure] an override for this behavior, and force a\nrelease to be published as either a **pre-release** or **stable release**. This\ncan be done via the [configuration file], or via [action inputs]:\n\n[configure]: #configuration\n[configuration file]: #the-configuration-file\n[action inputs]: #action-inputs\n\n```yaml\n# In .github/github-release-from-tag.yml:\nprerelease: true # or false\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    prerelease: \"true\" # or \"false\"\n```\n\n#### Example release stabilities\n\n| Tag name                             | Is SemVer? | Release stability |\n| :----------------------------------- | :--------- | :---------------- |\n| `1` / `v1`                           | no         | stable release    |\n| `1.2` / `v1.2`                       | no         | stable release    |\n| `1.2.3` / `v1.2.3`                   | yes        | stable release    |\n| `1.2.3+21AF26D3` / `v1.2.3+21AF26D3` | yes        | stable release    |\n| `0.1.0` / `v0.1.0`                   | yes        | pre-release       |\n| `1.2.3-alpha` / `v1.2.3-alpha`       | yes        | pre-release       |\n| `0` / `v0`                           | no         | pre-release       |\n| `0.1` / `v0.1`                       | no         | pre-release       |\n| `something-else`                     | no         | pre-release       |\n\n### Draft releases\n\nThis action can be [configured] to create draft releases. These draft releases\ncan then be published manually at some later time via GitHub. You can enable\nthis feature via the [configuration file], or via [action inputs]:\n\n[configured]: #configuration\n[configuration file]: #the-configuration-file\n[action inputs]: #action-inputs\n\n```yaml\n# In .github/github-release-from-tag.yml:\ndraft: true\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    draft: \"true\"\n```\n\n### Release name and body\n\nThis action generates a release **name** and **body** from your **tag annotation\nmessage**. Git already breaks your tag annotation messages into two parts that\nline up with each part of a GitHub release:\n\n- The tag annotation **subject** becomes the release **name**.\n- The tag annotation **body** is rendered as [Markdown], and used as the release\n  **body**.\n\n[markdown]: https://docs.github.com/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github\n\nThe tag annotation \"subject\" is just the first **paragraph** of the message. The\n\"body\" is everything that follows:\n\n    This is part of the subject.\n    This is also considered part of the subject.\n\n    This is the beginning of the body.\n    This is also part of the body.\n\n    The body can have multiple paragraphs.\n\n#### Markdown support\n\nFor the most part, [Markdown] \"just works\" how you would expect. You can write\nMarkdown in the \"body\" portion of your tag annotations, and it will be rendered\nin the body of the releases published by this action.\n\n[markdown]: https://docs.github.com/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github\n\n##### Markdown headings in tag annotation messages\n\nWhen authoring tag annotation messages, you might run into the issue that\nMarkdown **headings** are lines that start with a `#` character, which Git\ninterprets as a **comment**. You can get around this limitation by using the\nfollowing Git command to create the tag:\n\n    git tag --annotate --cleanup=whitespace --edit --message \"\" 1.0.0\n\nYou might want to add a **Git alias** to make it easier to remember the command:\n\n    git config --global alias.tag-md 'tag --annotate --cleanup=whitespace --edit --message \"\"'\n\nWith the above alias configured, you can then use `git tag-md` to create tags\nwith Markdown tag annotation bodies:\n\n    git tag-md 1.0.0\n\n##### Markdown heading anchors\n\nGitHub doesn't generate [section links] for Markdown headings in release bodies,\nlike it does for other Markdown content. This means that you normally can't link\ndirectly to a heading in a release body, or include links to headings in your\nrelease body markdown.\n\n[section links]: https://docs.github.com/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#section-links\n\nThis action solves this issue by generating **heading anchors** for each heading\nin the release body. These anchors work just like the ones generated for most\nMarkdown content on GitHub, and can be used to link directly to headings in your\nrelease body.\n\nFor example, if you have a heading in your release body like this:\n\n```markdown\n#### Support for turbo-encabulators\n\nFor a number of years now, work has been proceeding in order to bring perfection\nto the crudely conceived idea of a machine that would not only supply inverse\nreactive current for use in unilateral phase detractors, but would also be\ncapable of automatically synchronizing cardinal grammeters. Such a machine is\nthe Turbo-Encabulator.\n```\n\nThen you can link directly to this heading in your release body like so:\n\n```markdown\n### Added\n\n- Added support for [turbo-encabulators].\n\n[turbo-encabulators]: #support-for-turbo-encabulators\n```\n\nAnd once the release is published, you can also link directly to the heading in\nthe release body from external sources by adding the anchor to the end of the\nrelease URL, like so:\n\nhttps://github.com/ghalactic/github-release-from-tag/releases/v5.3.0#markdown-heading-anchors\n\n##### Markdown line breaks\n\nIt's common for tag annotation messages to be \"wrapped\" at a fixed column width,\nfor readability when viewed as plain text:\n\n    1.0.0\n\n    This provides an example of a Git tag annotation body that has been\n    \"hard wrapped\". This is a very common practice.\n\nIf we were to copy the body from the tag annotation message above directly into\nthe GitHub release, the line breaks would be interpreted as explicit line breaks\nin the final HTML, like so:\n\n\u003e This provides an example of a Git tag annotation body that has been\\\n\u003e \"hard wrapped\". This is a very common practice.\n\nMost people would probably consider this an undesirable result, and would rather\nthat the above two lines be combined into a single line in the resulting HTML,\nsimilar to how GitHub behaves when rendering `README.md` files.\n\nTo avoid this issue, line breaks that are not followed by another line break\n(also known as \"soft\" line breaks) are transformed into spaces before they are\nused in GitHub release bodies. Meaning the above tag annotation body would be\nrendered like so:\n\n[github's api]: https://docs.github.com/rest/markdown#render-a-markdown-document\n\n\u003e This provides an example of a Git tag annotation body that has been\n\u003e \"hard wrapped\". This is a very common practice.\n\n### Automated release notes\n\nThis action supports GitHub's [automatically generated release notes] feature.\nYou can enable this feature via the [configuration file], or via [action\ninputs]:\n\n[automatically generated release notes]: https://docs.github.com/repositories/releasing-projects-on-github/automatically-generated-release-notes\n[configuration file]: #the-configuration-file\n[action inputs]: #action-inputs\n\n```yaml\n# In .github/github-release-from-tag.yml:\ngenerateReleaseNotes: true\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    generateReleaseNotes: \"true\"\n```\n\nWhen enabled, automated release notes will be generated and appended to each\nrelease body. The release notes are based off of **pull requests**, and can be\n[configured to customize how they are generated].\n\n[configured to customize how they are generated]: https://docs.github.com/repositories/releasing-projects-on-github/automatically-generated-release-notes#configuring-automatically-generated-release-notes\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eExample automated release notes\u003c/strong\u003e\u003c/summary\u003e\n\u003cbr\u003e\n\n\u003e ## What's Changed\n\u003e\n\u003e - Add feature A by [@ezzatron] in [#5](#)\n\u003e - Add feature B by [@ezzatron] in [#6](#)\n\u003e - Fix bug A by [@ezzatron] in [#7](#)\n\u003e - Fix bug B by [@ezzatron] in [#8](#)\n\u003e - Add docs for feature A by [@ezzatron] in [#9](#)\n\u003e - Add docs for feature B by [@ezzatron] in [#10](#)\n\u003e\n\u003e ## New Contributors\n\u003e\n\u003e - [@ezzatron] made their first contribution in [#5](#)\n\u003e\n\u003e **Full Changelog**: https://github.com/owner/repo/commits/1.0.0\n\n[@ezzatron]: https://github.com/ezzatron\n\n\u003c/details\u003e\n\n### Release assets\n\nThis action supports uploading **release assets** — files that are associated\nwith a release, and made available for download from GitHub. Release assets\n**must exist before this action is run**, and can be specified via the\n[configuration file], or via [action inputs]:\n\n[configuration file]: #the-configuration-file\n\n```yaml\n# In .github/github-release-from-tag.yml:\nassets:\n  - path: path/to/asset-a\n  - path: path/to/asset-b-*\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    # Note the \"|\" character - this example uses a YAML multiline string.\n    assets: |\n      - path: path/to/asset-d\n```\n\n\u003e [!CAUTION]\n\u003e This action will **overwrite existing release assets** if their names match\n\u003e the assets configured for upload, or if their names match the\n\u003e [checksum assets]. Assets other than these will not be modified or removed.\n\n[checksum assets]: #checksum-assets\n\n\u003e [!TIP]\n\u003e Unlike other [action inputs], which typically override their equivalent\n\u003e [configuration file] options, assets specified via action inputs are\n\u003e **merged** with those specified in the configuration file.\n\n[action inputs]: #action-inputs\n[configuration file]: #the-configuration-file\n\nEach asset must have a `path` property, which is a file glob pattern supported\nby [`@actions/glob`]. If no matching file is found when the action is run, **the\nworkflow step will fail** (unless the asset is [configured to be optional]).\n\n[`@actions/glob`]: https://github.com/actions/toolkit/tree/main/packages/glob\n[configured to be optional]: #optional-release-assets\n\nIf **multiple files** match the `path` glob pattern, each file will be uploaded\nindividually. **This action does not handle archiving multiple assets for you.**\nIf you want to upload a `.zip` (or similar) file composed of multiple files, you\nmust build the archive yourself prior to running this action.\n\nIf **a single file** matches the `path` glob pattern, you can additionally\nspecify a custom `name` and/or `label` for the asset:\n\n```yaml\n# In .github/github-release-from-tag.yml:\nassets:\n  - path: path/to/asset-a.yaml\n    name: custom-name.yml\n    label: Labels can have spaces\n```\n\n```yaml\n# In your workflow (using YAML):\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    # Note the \"|\" character - this example uses a YAML multiline string.\n    assets: |\n      - path: path/to/asset-a.yaml\n        name: custom-name.yml\n        label: Labels can have spaces\n```\n\n```yaml\n# In your workflow (using JSON):\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    # Note the \"|\" character - this example uses a YAML multiline string.\n    assets: |\n      [{\n        \"path\": \"path/to/asset-a.yaml\",\n        \"name: \"custom-name.yml\",\n        \"label\": \"Labels can have spaces\"\n      }]\n```\n\nThe `name` property overrides the file name that will be used when the file is\nuploaded (and hence the filename seen by users who download the asset). The\n`label` property is a text field that gets used by GitHub when viewing a\nrelease's assets.\n\n#### Optional release assets\n\nAssets can be made \"optional\" — that is, they will simply be skipped if the\n`path` file glob pattern does not match any files. You can enable this behavior\nby setting the `optional` property to `true`:\n\n```yaml\n# In .github/github-release-from-tag.yml:\nassets:\n  - path: path/to/assets/*\n    optional: true\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    # Note the \"|\" character - this example uses a YAML multiline string.\n    assets: |\n      - path: path/to/assets/*\n        optional: true\n```\n\n#### Dynamic release assets\n\nIf you need to dynamically specify a list of assets to upload, you can use the\n`assets` [action input] with generated JSON (or YAML). How you generate the\nvalue for this input is up to you, but any value from a [context] (e.g.\n[an output from another step]) can be used, for example:\n\n[action input]: #action-inputs\n[context]: https://docs.github.com/actions/learn-github-actions/contexts\n[an output from another step]: https://docs.github.com/actions/learn-github-actions/contexts#steps-context\n\n```yaml\n# Executing a script that outputs JSON describing the assets to upload.\n- id: listAssets\n  run: echo \"assets=$(bash list-assets.sh)\" \u003e\u003e $GITHUB_OUTPUT\n\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    assets: ${{ steps.listAssets.outputs.assets }}\n```\n\n#### Checksum assets\n\nBy default, this action generates **checksum assets**. When a release has\nassociated assets specified, two checksum assets will be generated for the\nrelease:\n\n- `checksums.sha256` — A plaintext checksum file in [`sha256sum`] format.\n- `checksums.json` — A JSON file containing checksums for each asset.\n\n[`sha256sum`]: https://dashdash.io/1/sha256sum\n\nYou can disable this feature via the [configuration file], or via [action\ninputs]:\n\n[configuration file]: #the-configuration-file\n[action inputs]: #action-inputs\n\n```yaml\n# In .github/github-release-from-tag.yml:\nchecksum:\n  generateAssets: false\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    checksumGenerateAssets: \"false\"\n```\n\nChecksums for each asset are always included in the `assets` [action output],\neven when **checksum asset** generation is disabled.\n\n[action output]: #action-outputs\n\n\u003cdetails\u003e\n\u003csummary\u003eExample \u003ccode\u003echecksums.sha256\u003c/code\u003e\u003c/summary\u003e\n\n```\n3878a1aff7b0769be29e355922a89de794078db863cdc931d01e687168f06443  file-a.txt\nf97a35fc9ddddd6bbfe0244e7608ec342dba9ed18e7227db061997d32133edeb  file-b.zip\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003eExample \u003ccode\u003echecksums.json\u003c/code\u003e\u003c/summary\u003e\n\n```json\n{\n  \"sha256\": {\n    \"file-a.txt\": \"3878a1aff7b0769be29e355922a89de794078db863cdc931d01e687168f06443\",\n    \"file-b.zip\": \"f97a35fc9ddddd6bbfe0244e7608ec342dba9ed18e7227db061997d32133edeb\"\n  }\n}\n```\n\n\u003c/details\u003e\n\n### Release discussions\n\nThis action supports creating [GitHub Discussions] for releases. You can enable\nthis feature via the [configuration file], or via [action inputs]:\n\n[github discussions]: https://docs.github.com/discussions\n[configuration file]: #the-configuration-file\n[action inputs]: #action-inputs\n\n```yaml\n# In .github/github-release-from-tag.yml:\ndiscussion:\n  category: Announcements\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    discussionCategory: Announcements\n```\n\nWhen enabled, discussions will automatically be created and linked to each\npublished release. The discussion **title** and **body** will match the release\n**name** and **body**. The specified discussion category **must already exist**\nin the repo.\n\n### Reactions\n\nIn order to promote engagement with your releases, this action can create\n**reactions** like 👍, 😄, 🎉, ❤️, 🚀, and 👀.\n\nA typical user is more likely to add their own reaction if they can simply click\non an existing one — rather than be the first one to add a particular reaction,\nwhich takes more effort. You can enable this feature via the [configuration\nfile], or via [action inputs]:\n\n[configuration file]: #the-configuration-file\n[action inputs]: #action-inputs\n\n```yaml\n# In .github/github-release-from-tag.yml:\nreactions: [\"+1\", laugh, hooray, heart, rocket, eyes]\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    reactions: +1,laugh,hooray,heart,rocket,eyes\n```\n\nIf you've enabled [release discussion creation], reactions can also be created\nfor release discussions (which support a couple of additional reactions like 👎\nand 😕):\n\n```yaml\n# In .github/github-release-from-tag.yml:\ndiscussion:\n  category: Announcements\n  reactions: [\"+1\", \"-1\", laugh, hooray, confused, heart, rocket, eyes]\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    discussionCategory: Announcements\n    discussionReactions: +1,-1,laugh,hooray,confused,heart,rocket,eyes\n```\n\n[release discussion creation]: #release-discussions\n\n### Job summaries\n\nWhen a release is created or updated, a summary containing useful information\nand links will be displayed on the Actions run summary page:\n\n\u003cpicture\u003e\n  \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"/assets/images/release-summary-dark.svg\"\u003e\n  \u003cimg alt=\"Example release job summary\" src=\"/assets/images/release-summary-light.svg#gh-light-mode-only\"\u003e\n\u003c/picture\u003e\n\nYou can disable this feature via the [configuration file], or via\n[action inputs]:\n\n[configuration file]: #the-configuration-file\n[action inputs]: #action-inputs\n\n```yaml\n# In .github/github-release-from-tag.yml:\nsummary:\n  enabled: false\n```\n\n```yaml\n# In your workflow:\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    summaryEnabled: \"false\"\n```\n\n## Configuration\n\n\u003e [!TIP]\n\u003e Try to use as _little_ configuration as possible. Everything here is\n\u003e **optional**, and **the less configuration the better**.\n\n### The configuration file\n\nThis action supports an **optional** YAML configuration file, with options for\naffecting how releases are published:\n\n\u003e [!TIP]\n\u003e These options can also be specified by [action inputs]. A\n\u003e [JSON Schema definition] is also available.\n\n[action inputs]: #action-inputs\n[json schema definition]: https://ghalactic.github.io/github-release-from-tag/schema/config.v5.schema.json\n\n```yaml\n# .github/github-release-from-tag.yml\n\n# Get completion and validation when using the YAML extension for VS Code.\n# yaml-language-server: $schema=https://ghalactic.github.io/github-release-from-tag/schema/config.v5.schema.json\n\n# Set to true to produce releases in a draft state.\ndraft: true\n\n# Set to true to append automatically generated release notes to release bodies.\ngenerateReleaseNotes: true\n\n# Set to true or false to override the automatic tag name based pre-release\n# detection.\nprerelease: false\n\n# Reactions to create for releases.\nreactions: [\"+1\", laugh, hooray, heart, rocket, eyes]\n\nassets:\n  # A path is required for each asset.\n  - path: assets/text/file-a.txt\n\n  # The \"optional\" flag, name, and label are optional.\n  - path: assets/json/file-b.json\n    optional: true\n    name: custom-name-b.json\n    label: Label for file-b.json\n\nchecksum:\n  # Set to false to disable generation of checksum assets for releases.\n  generateAssets: false\n\ndiscussion:\n  # The category to use when creating the discussion.\n  category: category-a\n\n  # Reactions to create for discussions linked to releases.\n  reactions: [\"+1\", \"-1\", laugh, hooray, confused, heart, rocket, eyes]\n\nsummary:\n  # Set to false to disable GitHub Actions job summary creation.\n  enabled: false\n```\n\n### Action inputs\n\nThis action supports **optional** inputs for affecting how releases are\npublished:\n\n\u003e [!IMPORTANT]\n\u003e With the exception of `assets`, these inputs take precedence over any\n\u003e equivalent options specified in [the configuration file]. The\n\u003e [action metadata file] contains the actual definitions for these inputs.\n\n[the configuration file]: #the-configuration-file\n[action metadata file]: action.yml\n\n```yaml\n- uses: ghalactic/github-release-from-tag@v5\n  with:\n    # Set to \"true\" to produce releases in a draft state.\n    draft: \"true\"\n\n    # Set to \"true\" to append automatically generated release notes to the\n    # release body.\n    generateReleaseNotes: \"true\"\n\n    # Set to \"true\" or \"false\" to override the automatic tag name based\n    # pre-release detection.\n    prerelease: \"false\"\n\n    # Reactions to create for releases.\n    reactions: +1,laugh,hooray,heart,rocket,eyes\n\n    # Assets to be associated with releases, specified as YAML (or JSON), and\n    # merged with assets specified elsewhere. If you need a dynamic list, this\n    # input can be useful. See the section titled \"Dynamic release assets\".\n    assets: |\n      - path: assets/text/file-a.txt\n\n      - path: assets/json/file-b.json\n        optional: true\n        name: custom-name-b.json\n        label: Label for file-b.json\n\n    # Set to \"false\" to disable generation of checksum assets for the release.\n    generateChecksumAssets: \"false\"\n\n    # Use a custom GitHub token.\n    token: ${{ secrets.CUSTOM_GITHUB_TOKEN }}\n\n    # The category to use when creating the discussion.\n    discussionCategory: category-a\n\n    # Reactions to create for discussions linked to releases.\n    discussionReactions: +1,-1,laugh,hooray,confused,heart,rocket,eyes\n\n    # Set to \"false\" to disable GitHub Actions job summary creation.\n    summaryEnabled: \"false\"\n```\n\n## Action outputs\n\nThis action makes a number of outputs available:\n\n\u003e [!TIP]\n\u003e The [action metadata file] contains the actual definitions for these outputs.\n\u003e The example below should give you some idea what each output looks like. The\n\u003e outputs aren't actually YAML of course, it's just for explanatory purposes.\n\n[action metadata file]: action.yml\n\n```yaml\n# The ID of the published release.\nreleaseId: \"68429422\"\n\n# The URL of the published release.\nreleaseUrl: https://github.com/owner/repo/releases/tag/1.0.0\n\n# The asset upload URL for the published release (as an RFC 6570 URI Template).\nreleaseUploadUrl: https://uploads.github.com/repos/owner/repo/releases/68429422/assets{?name,label}\n\n# Contains \"true\" if a new release was created.\nreleaseWasCreated: \"true\"\n\n# The name of the published release.\nreleaseName: 1.0.0 Leopard Venom 🐆\n\n# The body of the published release.\nreleaseBody: |\n  This is the first _stable_ release 🎉\n\n  ## What's Changed ...\n\n# The avatar URL of the GitHub user who created the tag.\ntaggerAvatarUrl: https://avatars.githubusercontent.com/u/100152?u=2d625417e12ad2b9cf55a3897e9a36b1bc145133\u0026v=4\n\n# The username of the GitHub user who created the tag.\ntaggerLogin: ezzatron\n\n# The name of the tag that caused the release.\ntagName: 1.0.0\n\n# Contains \"true\" for any tag considered \"stable\".\ntagIsStable: \"true\"\n\n# Contains \"true\" for SemVer version tags.\ntagIsSemVer: \"true\"\n\n# The \"subject\" portion of the tag annotation.\ntagSubject: |\n  1.0.0\n  Leopard Venom 🐆\n\n# The \"body\" portion of the tag annotation.\ntagBody: |\n  This is the first\n  _stable_\n  release 🎉\n\n# The \"body\" portion of the tag annotation, rendered as Markdown. This\n# represents the Markdown after it has been \"processed\", and may differ greatly\n# from the original input Markdown.\ntagBodyRendered: This is the first _stable_ release 🎉\n\n# The generated release notes produced by GitHub. See \"Automated release notes\".\ngeneratedReleaseNotes: \"## What's Changed ...\"\n\n# The ID of the release discussion.\ndiscussionId: D_kwDOG4Ywls4APsqF\n\n# The unique number of the release discussion.\ndiscussionNumber: \"93\"\n\n# The URL of the release discussion.\ndiscussionUrl: https://github.com/owner/repo/discussions/93\n\n# A JSON array of objects describing the release assets.\nassets: |\n  [\n    {\n      \"apiUrl\": \"https://api.github.com/repos/owner/repo/releases/assets/67328106\",\n      \"downloadUrl\": \"https://github.com/owner/repo/releases/download/1.0.0/file.txt\",\n      \"id\": 67328106,\n      \"nodeId\": \"RA_kwDOG4Ywls4EA1hq\",\n      \"name\": \"file.txt\",\n      \"label\": \"Label for file.txt\",\n      \"state\": \"uploaded\",\n      \"contentType\": \"application/json\",\n      \"size\": 16,\n      \"downloadCount\": 0,\n      \"createdAt\": \"2022-06-02T09:37:56Z\",\n      \"updatedAt\": \"2022-06-02T09:37:56Z\",\n      \"checksum\": {\n        \"sha256\": \"2fef44d096530d162c859b5b4ec0895c308845cad1eebd7ef582c5ebd2dd787d\"\n      }\n    },\n    ...\n  ]\n```\n\n### Using action outputs\n\nAction outputs can be used to integrate with other steps in a workflow. Simply\nadd an `id` to the step that uses this action, and reference the output you\nneed as demonstrated below:\n\n```yaml\n- uses: ghalactic/github-release-from-tag@v5\n  id: publishRelease\n- env:\n    RELEASE_URL: ${{ steps.publishRelease.outputs.releaseUrl }}\n  run: echo Released to $RELEASE_URL\n```\n\nThe `assets` output is a JSON array, and needs to be decoded before its contents\ncan be accessed:\n\n\u003e [!TIP]\n\u003e The assets are ordered by their `name` property.\n\n```yaml\n- uses: ghalactic/github-release-from-tag@v5\n  id: publishRelease\n- env:\n    DOWNLOAD_URL: ${{ fromJSON(steps.publishRelease.outputs.assets)[0].downloadUrl }}\n  run: echo Download the first asset from $DOWNLOAD_URL\n```\n\n## GitHub Enterprise Server support\n\nThis action works with [GitHub Enterprise Server (GHES)]. Depending on how your\nenterprise is configured, you may have to work with an administrator to either:\n\n- [Use GitHub Connect to allow access to the action]; or\n- [Manually sync the action to your enterprise].\n\n[github enterprise server (ghes)]: https://docs.github.com/enterprise-server/admin/overview/about-github-enterprise-server\n[use github connect to allow access to the action]: https://docs.github.com/enterprise-server/admin/github-actions/managing-access-to-actions-from-githubcom/enabling-automatic-access-to-githubcom-actions-using-github-connect\n[manually sync the action to your enterprise]: https://docs.github.com/enterprise-server/admin/github-actions/managing-access-to-actions-from-githubcom/manually-syncing-actions-from-githubcom\n\n### GitHub Enterprise Server version feature support\n\nFeature support on GitHub Enterprise Server often lags behind other versions of\nGitHub. This action may not work correctly if you try to use features on an\nenterprise that does not have support for those features.\n\nHere are some key features that can be used by this action, and which version of\nGitHub Enterprise Server introduced support:\n\n| Feature                                                     | 3.1 | 3.2 | 3.3 | 3.4 | 3.5 | 3.6 |\n| :---------------------------------------------------------- | :-- | :-- | :-- | :-- | :-- | :-- |\n| [Release reactions][ghes-3-2-release-reactions]             | ❌  | ✅  | ✅  | ✅  | ✅  | ✅  |\n| [Generated release notes][ghes-3-4-generated-release-notes] | ❌  | ❌  | ❌  | ✅  | ✅  | ✅  |\n| [Discussions][ghes-3-6-discussions]                         | ❌  | ❌  | ❌  | ❌  | ❌  | ✅  |\n| [Job summaries][ghes-3-6-job-summaries]                     | ❌  | ❌  | ❌  | ❌  | ❌  | ✅  |\n\n[ghes-3-2-release-reactions]: https://docs.github.com/enterprise-server@3.2/rest/reactions#create-reaction-for-a-release\n[ghes-3-4-generated-release-notes]: https://docs.github.com/enterprise-server@3.4/admin/release-notes#releases-changes\n[ghes-3-6-discussions]: https://docs.github.com/enterprise-server@3.6/admin/release-notes#community-experience\n[ghes-3-6-job-summaries]: https://docs.github.com/enterprise-server@3.6/admin/release-notes#github-actions\n\n## FAQ\n\n### What format should I use for my release body?\n\nI recommend following [Keep a Changelog]. When it's time to release, just grab\nthe content from the **Unreleased** section and paste it into your tag\nannotation message.\n\n[keep a changelog]: https://keepachangelog.com/\n\n### Does this action work with [Semantic Release] / [Release Please]?\n\n[semantic release]: https://semantic-release.gitbook.io/\n[release please]: https://github.com/googleapis/release-please\n\nTechnically yes, but it's not recommended. These tools have their own solutions\nfor publishing GitHub releases which are better suited.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fghalactic%2Fgithub-release-from-tag","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fghalactic%2Fgithub-release-from-tag","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fghalactic%2Fgithub-release-from-tag/lists"}