![\"Release](\"docs/design/logo.svg\"){kind=logo}
\n\nDrafts your next release notes as pull requests are merged into master.
\n\n\n\n\n## Usage\n\nYou can use the\n[Release Drafter GitHub Action](https://github.com/marketplace/actions/release-drafter)\nin a\n[GitHub Actions Workflow](https://help.github.com/en/actions/about-github-actions)\nby configuring a YAML-based workflow file, e.g.\n`.github/workflows/release-drafter.yml`, with the following:\n\n```yaml\nname: Release Drafter\n\non:\n push:\n branches:\n - main\n - master\n\n# Permissions for default token (secrets.GITHUB_TOKEN)\npermissions:\n contents: write\n pull-requests: read\n\njobs:\n update_release_draft:\n runs-on: ubuntu-latest\n steps:\n - uses: release-drafter/release-drafter@v7\n with:\n config-name: release-drafter.yml # the default, loads '.github/release-drafter.yml'\n```\n\n### ✍️ Local CLI\n\nThe local CLI creates or updates a draft using the last published release as its\nstarting point. It reads authentication from `GITHUB_TOKEN`, `GH_TOKEN`, or the\nGitHub CLI.\n\n```sh\nnpx release-drafter owner/repository\n```\n\nFrom a source checkout, use `npm run cli -- owner/repository` instead.\n\nUse `--from` to override the starting commitish and `--release-version` to\noverride the resolved version:\n\n```sh\nnpx release-drafter owner/repository --from v8.0.0 --release-version 9.0.0\n```\n\nThe target commitish defaults to the repository's default branch; override it with\n`--to`. The CLI uses the same config loading as the action, including the fallback\nto the organization's `.github` repository. Use `--config` to select another\nconfig or `--dry-run` to print the generated release without creating or updating\nit.\n\nBy default, the CLI creates or updates a draft. Use `--publish` to publish it,\noptionally with `--prerelease` or `--latest`:\n\n```sh\nnpx release-drafter owner/repository --publish --prerelease\nnpx release-drafter owner/repository --publish --latest\n```\n\nEach release-mode flag accepts an optional `true` or `false` value, so\n`--latest false` can override a config that marks stable releases as latest.\nPrereleases are never marked as latest, matching the action's behavior.\n\n## Configuration\n\nThe action requires a configuration file. Default location is\n`.github/release-drafter.yml`, and will be fetched using octokit behind the\nscenes. You do not need to checkout your repository beforehand.\n\n> [!note] \n> For advanced scenarios, please read dedicated\n> [Configuration Loading](./docs/configuration-loading.md) article. (ex: dynamic\n> config, extending other files, fetch from another repo, etc...)\n\n### Example\n\nFor example, take the following `.github/release-drafter.yml` file in a\nrepository:\n\n```yml\ntemplate: |\n ## What’s Changed\n\n $CHANGES\n```\n\nAs pull requests are merged, a draft release is kept up-to-date listing the\nchanges, ready to publish when you’re ready:\n\n![\"Screenshot](\"docs/design/screenshot.png\")
\n\nThe following is a more complicated configuration, which categorises the changes\ninto headings, and automatically suggests the next version number:\n\n```yml\nname-template: \"v$RESOLVED_VERSION 🌈\"\ntag-template: \"v$RESOLVED_VERSION\"\ncategories:\n - title: \"🚀 Features\"\n semver-increment: minor\n when:\n labels:\n - \"feature\"\n - \"enhancement\"\n - title: \"🐛 Bug Fixes\"\n when:\n labels:\n - \"fix\"\n - \"bugfix\"\n - \"bug\"\n - title: \"🧰 Maintenance\"\n when:\n label: \"chore\"\n - type: \"pre-exclude\"\n when:\n label: \"skip-changelog\"\n - type: \"version-resolver\"\n semver-increment: \"major\"\n when:\n label: \"major\"\n - type: \"version-resolver\"\n semver-increment: \"patch\"\nchange-template: \"- $TITLE (#$NUMBER) $AUTHORS\"\nchange-title-escapes: '\\<*_&' # You can add # and @ to disable mentions, and add ` to disable code blocks.\ntemplate: |\n ## Changes\n\n $CHANGES\n```\n\n## Configuration Options\n\nYou can configure Release Drafter using the following key in your\n`.github/release-drafter.yml` file:\n\n| Key | Required | Description |\n| -------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `template` | Required | The template for the body of the draft release. Use [template variables](#template-variables) to insert values. |\n| `header` | Optional | Will be prepended to `template`. Use [template variables](#template-variables) to insert values. |\n| `footer` | Optional | Will be appended to `template`. Use [template variables](#template-variables) to insert values. |\n| `category-template` | Optional | The template to use for each category. Use [category template variables](#category-template-variables) to insert values. Default: `\"## $TITLE\"`. |\n| `name-template` | Optional | The template for the name of the draft release. For example: `\"v$NEXT_PATCH_VERSION\"`. |\n| `tag-template` | Optional | The template for the tag of the draft release. For example: `\"v$NEXT_PATCH_VERSION\"`. |\n| `tag-prefix` | Optional | A known prefix used to filter release tags. For matching tags, this prefix is stripped before attempting to parse the version. Default: `\"\"` |\n| `version-template` | Optional | The template to use when calculating the next version number for the release. Useful for projects that don't use semantic versioning. Default: `\"$MAJOR.$MINOR.$PATCH$PRERELEASE\"` |\n| `change-template` | Optional | The template to use for each merged pull request. Use [change template variables](#change-template-variables) to insert values. Default: `\"* $TITLE (#$NUMBER) $AUTHORS\"`. |\n| `change-author-template` | Optional | The template to use for each author in `$AUTHORS`. Supports `$AUTHOR` for the raw login/name and `$AUTHOR_MENTION` for a GitHub-formatted mention. Default: `\"$AUTHOR_MENTION\"`. |\n| `change-authors-separator` | Optional | The separator between authors in `$AUTHORS`. Default: `\", \"`. Use `\"\\n\"` with a list-style `change-author-template` for multiline output. |\n| `change-authors-final-separator` | Optional | A different separator before the final author in `$AUTHORS`, e.g. `\" and \"` produces `@octocat, @cchanche and @jetersen`. Defaults to `change-authors-separator`. |\n| `change-title-escapes` | Optional | Characters to escape in `$TITLE` when inserting into `change-template` so that they are not interpreted as Markdown format characters. Default: `\"\"` |\n| `no-changes-template` | Optional | The template to use for when there’s no changes. Default: `\"* No changes\"`. |\n| `categories` | Optional | Define how changes are filtered, grouped, and versioned. Categories support `type`, `when`, `exclusive`, `collapse-after`, and `semver-increment`. Refer to [Categorize Changes](#categorize-changes). |\n| `exclude-contributors` | Optional | Exclude specific usernames from the generated `$CONTRIBUTORS` variable. Refer to [Exclude Contributors](#exclude-contributors) to learn more about this option. |\n| `new-contributor-template` | Optional | The template to use for each new contributor in `$NEW_CONTRIBUTORS`. Use [new contributor template variables](#new-contributor-template-variables) to insert values. Default: `\"* $AUTHOR_MENTION made their first contribution in #$NUMBER\"`. |\n| `no-contributors-template` | Optional | The template to use for `$CONTRIBUTORS` when there's no contributors to list. Default: `\"No contributors\"`. |\n| `replacers` | Optional | Search and replace content in the generated changelog body. Refer to [Replacers](#replacers) to learn more about this option. |\n| `sort-by` | Optional | Sort changelog by merged_at or title. Can be one of: `merged_at`, `title`. Default: `merged_at`. |\n| `sort-direction` | Optional | Sort changelog in ascending or descending order. Can be one of: `ascending`, `descending`. Default: `descending`. |\n| `prerelease` | Optional | Whether to draft a prerelease, with changes since another prerelease (if applicable). Default `false`. |\n| `prerelease-identifier` | Optional | A string indicating an identifier (alpha, beta, rc, etc), to increment the prerelease version. This automatically enables `prerelease` when both options come from the same config location; explicit action inputs still take precedence. Default `''`. |\n| `include-pre-releases` | Optional | When looking for the last published release to scan changes up-to, include pre-releases. Has no effect if using `prerelease: true` (already enabled). Default `false`. |\n| `latest` | Optional | Mark the release as latest. Only works for published releases. Can be one of: `true`, `false`, `legacy`. Default `true`. |\n| `commitish` | Optional | The release target, i.e. branch, commit SHA, or fully qualified tag or pull request ref it should point to. Tag and pull request refs are resolved to commit SHAs. Pull request merge refs always run in dry-run mode because they point to ephemeral merge commits; set `dry-run: true` explicitly to acknowledge output-only behavior and suppress the warning. Defaults to the branch that release-drafter runs for, e.g. `master` when configured to run on pushes to `master`. |\n| `filter-by-range` | Optional | Filter releases that satisfies a semver range. Evaluates the tag name againts node's `semver.satisfies()`. Default : `\"*\"`. |\n| `filter-by-commitish` | Optional | Filter previous releases to consider only those with the target matching `commitish`. Default: `false`. |\n| `pull-request-limit` | Optional | Limit for associatedPullRequests API call. Use this when working with long-lived non-default branches. See #1354. Default: `5` |\n| `history-limit` | Optional | Size of the pagination window when walking the repo. Can avoid erratic 502s from Github. Default: `15` |\n\n## Template Variables\n\nYou can use any of the following variables in your `template`, `header` and\n`footer`:\n\n| Variable | Description |\n| ------------------- | --------------------------------------------------------------------------------------------------------------------- |\n| `$CHANGES` | The markdown list of pull requests that have been merged. |\n| `$CONTRIBUTORS` | A comma separated list of contributors to this release (pull request authors, commit authors, and commit committers). |\n| `$NEW_CONTRIBUTORS` | A Markdown list of pull request authors making their first contribution and the corresponding pull request. |\n| `$PREVIOUS_TAG` | The previous releases’s tag. |\n| `$REPOSITORY` | Current Repository |\n| `$OWNER` | Current Repository Owner |\n\n## Category Template Variables\n\nYou can use any of the following variables in `category-template`:\n\n| Variable | Description |\n| -------- | ------------------------------------ |\n| `$TITLE` | The category title, e.g. `Features`. |\n\n## Next Version Variables\n\nYou can use any of the following variables in your `template`, `header`,\n`footer`, `name-template` and `tag-template`:\n\n| Variable | Description |\n| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `$NEXT_PATCH_VERSION` | The next patch version number. For example, if the last tag or release was `v1.2.3`, the value would be `v1.2.4`. This is the most commonly used value. |\n| `$NEXT_MINOR_VERSION` | The next minor version number. For example, if the last tag or release was `v1.2.3`, the value would be `v1.3.0`. |\n| `$NEXT_MAJOR_VERSION` | The next major version number. For example, if the last tag or release was `v1.2.3`, the value would be `v2.0.0`. |\n| `$NEXT_PRERELEASE_VERSION` | The next prerelease suffix. Depends on `prerelease-identifier`. Ex: `v1.2.3-beta.3`. Default : `''` |\n| `$RESOLVED_VERSION` | The next resolved version number, based on which categories the matching changes end up in and the `semver-increment` configured on those categories. Refer to [Version Resolver](#version-resolver) to learn more about this. |\n\n### Next Version Component Helpers\n\nFor each of the `$NEXT_{MAJOR,MINOR,PATCH}_VERSION` variables, additional\ncomponent helper variables are available that extract individual version\ncomponents:\n\n| Variable | Description |\n| ------------------------------------- | ------------------------------------------------------------------ |\n| `$NEXT_MAJOR_VERSION_MAJOR` | Major component of `$NEXT_MAJOR_VERSION`. |\n| `$NEXT_MAJOR_VERSION_MINOR` | Minor component of `$NEXT_MAJOR_VERSION`. |\n| `$NEXT_MAJOR_VERSION_PATCH` | Patch component of `$NEXT_MAJOR_VERSION`. |\n| `$NEXT_MINOR_VERSION_MAJOR` | Major component of `$NEXT_MINOR_VERSION`. |\n| `$NEXT_MINOR_VERSION_MINOR` | Minor component of `$NEXT_MINOR_VERSION`. |\n| `$NEXT_MINOR_VERSION_PATCH` | Patch component of `$NEXT_MINOR_VERSION`. |\n| `$NEXT_PATCH_VERSION_MAJOR` | Major component of `$NEXT_PATCH_VERSION`. |\n| `$NEXT_PATCH_VERSION_MINOR` | Minor component of `$NEXT_PATCH_VERSION`. |\n| `$NEXT_PATCH_VERSION_PATCH` | Patch component of `$NEXT_PATCH_VERSION`. |\n| `$NEXT_PRERELEASE_VERSION_PRERELEASE` | Prerelease segment of `$NEXT_PRERELEASE_VERSION`. Ex : `'-beta.3'` |\n\n## Version Template Variables\n\nYou can use any of the following variables in `version-template` to format the\n[Next Version Variables](#next-version-variables):\n\n| Variable | Description |\n| ------------- | --------------------------------------------------------------- |\n| `$PATCH` | The patch version number. |\n| `$MINOR` | The minor version number. |\n| `$MAJOR` | The major version number. |\n| `$PRERELEASE` | The prerelease suffix (for example `-rc.0`) or an empty string. |\n\nYou may want to use this when producing non semver output.\n\n```yaml\nversion-template: \"ver $MAJOR\"\n```\n\n> [!IMPORTANT]\n>\n> If you want the next release-drafter run to parse your version, stick to\n> versions parseable by semver.coerce() (we enbale `loose` mode)\n>\n> ```ts\n> semver.coerce(\"ver 1\", true); // { version: '1.0.0' }\n> ```\n>\n> If you simply want a verbose title for your releases, use the `name-template`\n> config, and leave versions strictly semver-compliant.\n\n## Version Resolver\n\nAny category with `semver-increment` contributes to `$RESOLVED_VERSION`.\nUse `type: version-resolver` categories when you want version resolution rules\nthat do not also render a changelog section.\n\nBefore version resolution runs, any `pre-include` and `pre-exclude` categories\nfilter the candidate pull requests. After that:\n\n- `type: changelog` categories contribute only for pull requests that end up\n assigned to that changelog category\n- `type: version-resolver` categories contribute from their own matches without\n rendering a changelog section\n- the highest matching increment wins across both category types\n\nCategory order matters when `exclusive: true` is used. Exclusivity is evaluated\nindependently for changelog categories and version-resolver categories.\n\n```yml\ncategories:\n - type: \"version-resolver\"\n semver-increment: \"major\"\n when:\n label: \"major\"\n - type: \"version-resolver\"\n semver-increment: \"minor\"\n when:\n label: \"minor\"\n - type: \"version-resolver\"\n semver-increment: \"patch\"\n when:\n label: \"patch\"\n - type: \"version-resolver\"\n semver-increment: \"patch\"\n```\n\nThe example above:\n\n- uses matching categories to resolve `major`, `minor`, or `patch`\n- uses the category with no `when` as the fallback when nothing else matches\n- picks the highest semver increment across matching categories\n\n## New Contributor Template Variables\n\nYou can use any of the following variables in `new-contributor-template`:\n\n| Variable | Description |\n| ----------------- | --------------------------------------------------------------------------- |\n| `$AUTHOR` | The new contributor’s username, e.g. `gracehopper`. |\n| `$AUTHOR_MENTION` | The new contributor’s GitHub mention, e.g. `@gracehopper`. |\n| `$AUTHOR_URL` | The URL of the new contributor’s GitHub profile, e.g. `https://github.com/gracehopper`. |\n| `$NUMBER` | The number of the contributor’s first pull request, e.g. `42`. |\n| `$URL` | The URL of the contributor’s first pull request, e.g. `https://github.com/octocat/repo/pull/42`. |\n\n## Change Template Variables\n\nYou can use any of the following variables in `change-template`:\n\n| Variable | Description |\n| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `$NUMBER` | The number of the pull request, e.g. `42`. |\n| `$CATEGORY` | The title of the category that matched the pull request, preserving its configured case. Empty for uncategorized pull requests. |\n| `$TITLE` | The title of the pull request, e.g. `Add alien technology`. Any characters excluding @ and # matching `change-title-escapes` will be prepended with a backslash so that they will appear verbatim instead of being interpreted as markdown format characters. @s and #s if present in `change-title-escapes` will be appended with an HTML comment so that they don't become mentions. |\n| `$AUTHOR` | The pull request author’s username, e.g. `gracehopper`. |\n| `$AUTHOR_URL` | The pull request author’s GitHub profile URL, e.g. `https://github.com/gracehopper`. |\n| `$AUTHORS` | The pull request author and its associated commit authors rendered with `change-author-template` and joined with `change-authors-separator`, with the pull request author first. |\n| `$BODY` | The body of the pull request e.g. `Fixed spelling mistake`. |\n| `$URL` | The URL of the pull request e.g. `https://github.com/octocat/repo/pull/42`. |\n| `$BASE_REF_NAME` | The base name of of the base Ref associated with the pull request e.g. `master`. |\n| `$HEAD_REF_NAME` | The head name of the head Ref associated with the pull request e.g. `my-bug-fix`. |\n\nFor a multiline author list, render each author with `$AUTHOR` and join them\nwith a newline:\n\n```yaml\ncategories:\n - title: bug\n when:\n label: bug\n - title: todo\ncategory-template: \"\"\nchange-template: |-\n - type: $CATEGORY\n message: |-\n $TITLE\n pull: $NUMBER\n authors:\n $AUTHORS\nchange-author-template: \"- $AUTHOR\"\nchange-authors-separator: \"\\n \"\n```\n\nUse `$AUTHOR_MENTION` instead of `$AUTHOR` in `change-author-template` when\nGitHub mentions are desired. GitHub App bots are rendered as linked mentions,\nfor example `[@dependabot[bot]](https://github.com/apps/dependabot)`.\n`$CATEGORY` preserves `categories[].title`; configure the title with the casing\nrequired by the output.\n\n## Categorize Changes\n\nWith the `categories` option you can describe the full change classification\npipeline:\n\n- `type: changelog` groups matching changes in the rendered release notes\n- `type: pre-include` keeps only matching changes for later processing\n- `type: pre-exclude` removes matching changes before changelog generation\n- `type: version-resolver` affects `$RESOLVED_VERSION` without rendering a\n changelog section\n\n`pre-include` always runs before `pre-exclude`, and both category types affect\nboth changelog generation and version resolution.\n\nCategories are evaluated in the order they are defined. By default, a pull\nrequest can match multiple categories of the same type. Setting `exclusive:\ntrue` on a `changelog` or `version-resolver` category stops later categories of\nthat same type from also matching the same pull request.\n\nEach category supports the following keys:\n\n| Key | Applies to | Description |\n| ------------------ | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `type` | All categories | Category behavior. Defaults to `changelog`. |\n| `title` | `changelog` | Required for changelog categories because `category-template` renders it. Ignored for `pre-include`, `pre-exclude`, and `version-resolver`. |\n| `when` | All categories | Match conditions. Omit it or use an empty array to match all changes. |\n| `exclusive` | `changelog`, `version-resolver` | Prevents later categories of the same type from also matching the same pull request. Defaults to `false`. |\n| `collapse-after` | `changelog` | Collapses long changelog sections into `![\"Screenshot](\"docs/design/screenshot-2.png\")
\n\nAdding such labels to your PRs can be automated by using the embedded\n[Autolabeler action](#autolabeler).\n\nOptionally you can add a `collapse-after` entry to your category item, if the\ncategory has more than the defined `collapse-after` pull requests then it will\nshow all pull requests collapsed for that category. Setting `collapse-after` to\n`0` will always collapse the category regardless of the number of pull requests,\nand setting it to `-1` disables collapsing.\nAppend the `collapse-after` integer to your category as following:\n\n```yml\ncategories:\n - title: \"⬆️ Dependencies\"\n collapse-after: 3\n when:\n label: \"dependencies\"\n```\n\n## Exclude Changes\n\nThe recommended way to exclude changes is a `type: pre-exclude` category.\nFor example, append the following to your\n`.github/release-drafter.yml` file:\n\n```yml\ncategories:\n - type: \"pre-exclude\"\n when:\n label: \"skip-changelog\"\n```\n\nChanges with the label \"skip-changelog\" will now be excluded from the\nrelease draft.\n\n## Include Changes\n\nThe recommended way to include only a subset of changes is a\n`type: pre-include` category. Only changes that match at least one\n`pre-include` category are kept for the rest of the pipeline. For example,\nappend the following to your\n`.github/release-drafter.yml` file:\n\n```yml\ncategories:\n - type: \"pre-include\"\n when:\n labels:\n - \"app-foo\"\n```\n\nChanges with the label \"app-foo\" will be the only changes included\nin the release draft.\n\n## Exclude Contributors\n\nBy default, the `$CONTRIBUTORS` variable will contain the names or usernames of\nall the contributors of a release. The `exclude-contributors` option allows you\nto remove certain usernames from that list. This can be useful if don't wish to\ninclude yourself, to better highlight only the third-party contributions.\n\n```yml\nexclude-contributors:\n - \"myusername\"\n```\n\n## Replacers\n\nYou can search and replace content in the generated changelog body, using\nregular expressions, with the `replacers` option. Each replacer is applied in\norder.\n\n```yml\nreplacers:\n - search: '/CVE-(\\d{4})-(\\d+)/g'\n replace: \"https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-$1-$2\"\n - search: \"myname\"\n replace: \"My Name\"\n - search: \"/- ([a-z])/g\"\n replace: '- \\u$1' # Uppercase the first letter of each changelog entry\n```\n\n`search` will be parsed to a RegExp, and `replace` supports substitution in the\n[same flavour VSCode does](https://code.visualstudio.com/docs/editing/codebasics#_case-changing-in-regex-replace).\n\n## Autolabeler\n\nYou can add automatically a label into a pull request, with the `autolabeler`\naction.\n\n```yaml\nname: Auto Label\n\non:\n pull_request:\n # Only following types are handled by the action, but one can default to all as well\n types: [opened, reopened, synchronize]\n # pull_request_target event is required for autolabeler to support PRs from forks\n # pull_request_target:\n # types: [opened, reopened, synchronize]\n\npermissions:\n contents: read\n\njobs:\n auto_label:\n permissions:\n pull-requests: write\n runs-on: ubuntu-latest\n steps:\n # runs autolabeler\n - uses: release-drafter/release-drafter/autolabeler@v7\n```\n\nAvailable matchers are `files` (glob), `branch` (regex), `title` (regex) and\n`body` (regex). Matchers are evaluated independently; the label will be set if\nat least one of the matchers meets the criteria.\n\n```yml\n# .github/release-drafter.yml\nautolabeler:\n - label: \"chore\"\n files:\n - \"*.md\"\n branch:\n - '/docs{0,1}\\/.+/'\n - label: \"bug\"\n branch:\n - '/fix\\/.+/'\n title:\n - \"/fix/i\"\n - label: \"enhancement\"\n branch:\n - '/feature\\/.+/'\n body:\n - \"/JIRA-[0-9]{1,4}/\"\n\n# ... rest of release-drafter config\n```\n\n## Prerelease workflow\n\nRelease draft supports working with prereleases. It expects your workflow to be\n:\n\n- A stable release is published, ex: `v3.5.0`\n- You merge or add meaningful changes your users may want to see, but you are\n not quite ready for production\n- You publish a prerelease, ex: `v3.5.0-rc.1`\n- You merge more changes\n- You publish another prerelease, ex: `v3.5.0-rc.2`\n- You decide code is ready for production, you publish `v3.5.1` (or another\n increment based on your changes)\n\nWith release-drafter, you can draft each of these releases and prereleases with\nthe appropriate content using parameter '`prerelease`' and\n'`prerelease-identifier`' - available as either an input of from the\nconfig-file.\n\n```yaml\njobs:\n update_full_release_draft:\n runs-on: ubuntu-latest\n steps:\n - uses: release-drafter/release-drafter@v6\n with:\n prerelease: false # the default\n # ... rest of your config\n update_prerelease_draft:\n runs-on: ubuntu-latest\n steps:\n - uses: release-drafter/release-drafter@v6\n with:\n prerelease: true\n prerelease-identifier: \"rc\" # Use semver identifiers : alpha, beta, rc, etc\n```\n\nHere, both jobs run in parallel every time you add changes to the configured\nbranch.\n\n- `update_full_release_draft` will pile-up changes since `v3.5.0` inside a draft\n for `v3.5.1` (or `v3.6.0` or `v4.0.0`, depending on your config)\n- `update_prerelease_draft` will pile-up changes since the last prerelease in a\n prerelease-draft. Changes are :\n - if no previous (published) prereleases are found - changes since `v3.5.0` in\n a draft for `v3.5.0-rc.1` (prerelease-draft)\n - or if `v3.5.0-rc.1` exists (published) already - changes since `v3.5.0-rc.1`\n in a draft for `v3.5.0-rc.2` (prerelease-draft)\n\nSome users like to run `update_prerelease_draft` with `publish: true`, such as\nprereleases are published immediately without the need for human intervention\n(or an external automation). Since prereleases are not meant to be stable in the\nfirst place, automation may be an acceptable risk for you too.\n\n> [!IMPORTANT]\n>\n> - `prerelease-identifier` is not required when `prerelease` is enabled, but\n> your prerelease may not be named after / be associated with a tag that is\n> semver-compliant to an actual prerelease.\n> - when specified, `prerelease-identifier` enables `prerelease: true` if both values come from the same config location; explicit action inputs still take precedence over config file values\n\nIf you want your stable releases to include changes since the last prerelease\ninstead of the last stable release, use `include-pre-releases: true`. This can\nreduce the number of changes included in the stable release body, but diverges\nfrom the standard workflow depicted above.\n\n## Projects that don't use Semantic Versioning\n\nIf your project doesn't follow [Semantic Versioning](https://semver.org) you can\nstill use Release Drafter, but you may want to set the `version-template` option\nto customize how the `$NEXT_{PATCH,MINOR,MAJOR}_VERSION` environment variables\nare generated.\n\nFor example, if your project doesn't use patch version numbers, you can set\n`version-template` to `$MAJOR.$MINOR`. If the current release is version 1.0,\nthen `$NEXT_MINOR_VERSION` will be `1.1`.\n\n## Action Inputs\n\nThe Release Drafter GitHub Action accepts a number of optional inputs directly\nin your workflow configuration. These will typically override default behavior\nspecified in your `release-drafter.yml` config.\n\n| Input | Description |\n| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `config-name` | If your workflow requires multiple release-drafter configs it be helpful to override the config-name. The config should still be located inside `.github` as that's where we are looking for config files. |\n| `token` | Access token used to make requests against the GitHub API. Defaults to `${{ github.token }}` |\n| `dry-run` | When enabled, no write operations (creating/updating releases or adding labels) are performed. Instead, the action logs what it would have done. Default : `false` |\n| `name` | The name that will be used in the GitHub release that's created or updated. This will override any `name-template` specified in your `release-drafter.yml` if defined. |\n| `tag` | The tag name to be associated with the GitHub release that's created or updated. This will override any `tag-template` specified in your `release-drafter.yml` if defined. |\n| `filter-by-range` | Filter releases that satisfies a semver range. Evaluates the tag name againts node's `semver.satisfies()`. |\n| `version` | The version to be associated with the GitHub release that's created or updated. This will override any version calculated by the release-drafter. |\n| `publish` | A boolean indicating whether the release being created or updated should be immediately published. This may be useful if the output of a previous workflow step determines that a new version of your project has been (or will be) released, as with [`salsify/action-detect-and-tag-new-version`](https://github.com/salsify/action-detect-and-tag-new-version). |\n| `prerelease` | Whether to draft a prerelease, with changes since another prerelease (if applicable). Default `false`. |\n| `prerelease-identifier` | A string indicating an identifier (alpha, beta, rc, etc), to increment the prerelease version. This automatically enables `prerelease` when both options come from the same config location; explicit action inputs still take precedence. Default `''`. |\n| `include-pre-releases` | When looking for the last published release to scan changes up-to, include pre-releases. Has no effect if using `prerelease: true` (already enabled). Default `false`. |\n| `latest` | A string indicating whether the release being created or updated should be marked as latest. |\n| `commitish` | The release target: a branch, commit SHA, or fully qualified tag or pull request ref. Tag and pull request refs are resolved to commit SHAs. Pull request merge refs force output-only dry-run mode and disable publishing. |\n| `header` | A string that would be added before the template body. |\n| `footer` | A string that would be added after the template body. |\n\n## Action Outputs\n\nThe Release Drafter GitHub Action sets a couple of outputs which can be used as\ninputs to other Actions in the workflow\n([example](https://github.com/actions/upload-release-asset#example-workflow---upload-a-release-asset)).\n\n| Output | Description |\n| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `id` | The ID of the release that was created or updated. |\n| `name` | The name of this release. |\n| `tag_name` | The name of the tag associated with this release. |\n| `body` | The body of the drafted release, useful if it needs to be included in files. |\n| `html_url` | The URL users can navigate to in order to view the release. i.e. `https://github.com/octocat/Hello-World/releases/v1.0.0`. |\n| `upload_url` | The URL for uploading assets to the release, which could be used by GitHub Actions for additional uses, for example the [`@actions/upload-release-asset GitHub Action`](https://www.github.com/actions/upload-release-asset). |\n| `resolved_version` | Version resolved by [Version Resolver](#version-resolver). i.e. `6.3.1` |\n| `major_version` | Major part of resolved version by [Version Resolver](#version-resolver). i.e. `6` for version `6.3.1` |\n| `minor_version` | Minor part of resolved version by [Version Resolver](#version-resolver). i.e. `3` for version `6.3.1` |\n| `patch_version` | Patch part of resolved version by [Version Resolver](#version-resolver). i.e. `1` for version `6.3.1` |\n\n## Programmatic API\n\nThe drafter flow is also available as a library export:\n\n```js\nimport { draftRelease } from 'release-drafter/drafter'\n\nconst result = await draftRelease({\n repo: { owner: 'owner', repo: 'repository' },\n token: process.env.GITHUB_TOKEN,\n previousCommitish: 'v1.0.0',\n publish: false,\n})\n\nconsole.log(result.releasePayload)\n```\n\nIt uses the same configuration loading, release generation, publication controls,\nand pull request merge-ref safeguards as the action and CLI. Pass a `logger` with\n`debug`, `info`, `warning`, and `error` methods to receive the same lifecycle\nmessages; library logging is silent by default. An existing `octokit` client can\nalso be injected.\n\n## GitHub Enterprise Server (GHES)\n\nIn GitHub Actions, Release Drafter uses `@actions/github` in a thin runtime\nadapter. This preserves the Actions Toolkit's proxy handling and automatically\nuses `GITHUB_API_URL` for GHES.\n\nThe CLI and programmatic API construct an ESM Octokit client directly without\nimporting the Actions runtime. The CLI honors `GITHUB_API_URL`; when using\n`HTTP_PROXY` or `HTTPS_PROXY`, enable Node's environment proxy support with\n`NODE_USE_ENV_PROXY=1`. Programmatic callers can pass `apiUrl` for API requests\nand `serverUrl` for generated web links, or inject a preconfigured `octokit`\nclient.\n\n## Contributing\n\nThird-party contributions are welcome! 🙏🏼 See\n[CONTRIBUTING.md](docs/CONTRIBUTING.md) for step-by-step instructions.\n\n> [!IMPORTANT]\n>\n> Before pushing, run `npm run all` to format, lint, type-check, test, and\n> regenerate all build artifacts. The CI pipeline enforces that no uncommitted\n> changes remain after these steps.\n\nIf you need help or have a question, let us know via\n[a GitHub issue](https://github.com/release-drafter/release-drafter/issues/new).\n","readmeFilename":"README.md","_rev":"1-3483c59139a4a948be212e65d8db66ea"}