{"id":16759190,"url":"https://github.com/alcalzone/release-script","last_synced_at":"2025-03-15T13:31:03.587Z","repository":{"id":36436278,"uuid":"220249621","full_name":"AlCalzone/release-script","owner":"AlCalzone","description":"Painless release management for Node.js projects","archived":false,"fork":false,"pushed_at":"2024-03-25T12:10:34.000Z","size":3366,"stargazers_count":15,"open_issues_count":29,"forks_count":11,"subscribers_count":3,"default_branch":"master","last_synced_at":"2024-04-14T07:56:18.449Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","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/AlCalzone.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}},"created_at":"2019-11-07T13:59:10.000Z","updated_at":"2024-04-15T20:36:43.000Z","dependencies_parsed_at":"2024-04-15T20:35:57.736Z","dependency_job_id":"62a69fa4-20a3-4d0b-b2b4-0478c9d2afbe","html_url":"https://github.com/AlCalzone/release-script","commit_stats":{"total_commits":226,"total_committers":7,"mean_commits":"32.285714285714285","dds":0.2920353982300885,"last_synced_commit":"0a286293292dc242c053e64292dcb09011016539"},"previous_names":[],"tags_count":67,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AlCalzone%2Frelease-script","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AlCalzone%2Frelease-script/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AlCalzone%2Frelease-script/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/AlCalzone%2Frelease-script/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/AlCalzone","download_url":"https://codeload.github.com/AlCalzone/release-script/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243735808,"owners_count":20339533,"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":[],"created_at":"2024-10-13T04:07:32.688Z","updated_at":"2025-03-15T13:31:02.828Z","avatar_url":"https://github.com/AlCalzone.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# AlCalzone's Release Script\n\nAutomate the monotonous tasks when it comes to releasing new versions of your project. The features include:\n\n-   Bump the version in `package.json` (and `package-lock.json`)\n-   Update the changelog headline with the new version and release date whenever a release is made\n-   Move old changelog entries into another file\n-   Add the changelog to the release commit and create a tag for it.\n-   Support for monorepos managed with `lerna` or `yarn workspaces` (using additional `yarn` plugins)\n-   Support for custom scripts during the release lifecycle\n-   Check licenses for outdated copyrights\n-   Dry runs and checking for errors\n-   **ioBroker only**:\n    -   Bump the version in `io-package.json`\n    -   Update the `news` in `io-package.json` and auto-translate the changelog to the other languages\n    -   Remove old `news`\n\nTogether with the corresponding **Github Actions** workflow (more on that below) this enables auto-publishing on `npm` and `Github Releases` if the build was successful.\n\n## Installation\n\n1. Add this module to your `devDependencies`:\n\n    ```bash\n    npm i -D @alcalzone/release-script\n    ```\n\n2. Add a new `npm` script in `package.json`:\n\n    ```jsonc\n    \"scripts\": {\n        // ... other scripts ...\n        \"release\": \"release-script\"\n    }\n    ```\n\n3. Add a placeholder to `README.md` (for your own convenience)\n\n    ```md\n    ## Changelog\n\n    \u003c!--\n      Placeholder for the next version (at the beginning of the line):\n      ### **WORK IN PROGRESS**\n    --\u003e\n    ```\n\n    or `CHANGELOG.md` if you prefer to have a separate changelog (notice that there is one less `#`):\n\n    ```md\n    # Changelog\n\n    \u003c!--\n      Placeholder for the next version (at the beginning of the line):\n      ## **WORK IN PROGRESS**\n    --\u003e\n    ```\n\n4. If necessary (e.g. for custom versioning steps) use a [config file](#configuration-with-a-config-file)\n\n## Usage\n\nIn order to use this script, you need to maintain the changelog in either `README.md` or `CHANGELOG.md`, because every release must have a changelog. To let the script know which changes are new, use the placeholder:\n\n```md\n# Changelog\n\n\u003c!--\n    Placeholder for the next version (at the beginning of the line):\n    ## **WORK IN PROGRESS**\n--\u003e\n\n## **WORK IN PROGRESS**\n\n-   Did some changes\n-   Did some more changes\n\n## v0.0.1 (2020-01-01)\n\nInitial release\n```\n\n### Separate changelog for old entries\n\nIf you are using `README.md`, the script can automatically move old changelog entries to `CHANGELOG_OLD.md` if that exists. The most recent entries are kept in `README.md`. To use this feature, simply create a `CHANGELOG_OLD.md` and give it a headline you like, e.g.\n\n```md\n# Older changes\n```\n\n### Add free text in the changelog entry headline\n\nYou can add free text after the placeholder:\n\n```md\n## **WORK IN PROGRESS** - 2020 Doomsday release\n```\n\nwill be turned into\n\n```md\n## 1.2.3 (2020-02-02) - 2020 Doomsday release\n```\n\nfor example.\n\n### Command line\n\nOnce you are ready to release the changes, commit everything so the working tree is clean. Also make sure that you are on the `master` branch. Now you can create a release by executing:\n\n```\nnpm run release [\u003creleaseType\u003e [\u003cpostfix\u003e]] -- [options]\n```\n\nor\n\n```\nyarn release [\u003creleaseType\u003e [\u003cpostfix\u003e]] [options]\n```\n\n\u003e When using `npm`, don't forget the extra `--` before specifying options!\n\nYou can choose between the following release types:\nThe available release types are:\n\n| Release type | Description / when to use                                                                                                                                                                                       | Example                             |\n| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- |\n| `major`      | Breaking changes are introduced. This may include new features and bugfixes.                                                                                                                                    | `0.9.8` -\u003e `1.0.0`                  |\n| `premajor`   | Like `major`, but to provide test versions before the final release. **WARNING:** Using this multiple times increases the major version each time.                                                              | `0.9.8` -\u003e `1.0.0-0` -\u003e `2.0.0-0`   |\n| `minor`      | A new feature was added **without** breaking things. This may include bugfixes.                                                                                                                                 | `0.9.8` -\u003e `0.10.0`                 |\n| `preminor`   | Like `minor`, but to provide test versions before the final release. **WARNING:** Using this multiple times increases the minor version each time.                                                              | `0.9.8` -\u003e `0.10.0-0` -\u003e `0.11.0-0` |\n| `patch`      | A bug was fixed without adding new functionality.                                                                                                                                                               | `0.9.8` -\u003e `0.9.9`                  |\n| `prepatch`   | Like `patch`, but to provide test versions before the final release. **WARNING:** Using this multiple times increases the patch version each time.                                                              | `0.9.8` -\u003e `0.9.9-0` -\u003e `0.9.10-0`  |\n| `prerelease` | Increases only the prerelease suffix. If the current version is not a prerelease, this behaves like `prepatch`. You might want to use this to create multiple test versions (e.g. multiple `premajor` versions) | `0.9.8` -\u003e `0.9.9-0` -\u003e `0.9.9-1`   |\n\nFor the `pre*` release types, you can optioinally provide a custom postfix, e.g. `beta`. For example, `npm run release prepatch beta` would result in the following bump: `0.9.8 -\u003e 0.9.9-beta.0`.\n\n\u003e If you omit the `releaseType` or `postfix` options, the release script will ask you for the desired version.\n\n### Command line options\n\nThe release script includes a small set of command line options by default. Each loaded plugin may add additional options. Those are described under the corresponding plugin.\n\n#### Show help (`--help` or `-h`)\n\nExample:\n\n```\nnpm run release -- --help\n```\n\n#### Dry run (`--dry`)\n\nThe release script makes it possible to test the command before actually changing anything. To do so, use the `--dry` argument. Take care to include the first set of hyphens (`-- --dry`) in the command or **it won't be a dry run**. Here's an example of a dry run that tells you what it would do and that it would fail due to uncommitted changes:  \n![dry run](./docs/dryrun.png)\n\n#### Configuration file (`--config` or `-c`)\n\nInstead of manually providing all options, you can configure the release process with a configuration file. This must be a JSON file\n\n```jsonc\n{\n\t// Boolean, number, string as is:\n\t\"dry\": false,\n\t// Arrays:\n\t\"plugins\": [\"iobroker\", \"lerna\"],\n\t// Objects\n\t\"exec\": {\n\t\t\"before_commit\": \"echo Hello World!\"\n\t}\n}\n```\n\nor a JS module if you like to do fancy stuff\n\n```js\nmodule.exports = {\n\tdry: Math.random() * 1000 \u003e 500,\n};\n```\n\nExample:\n\n```\nnpm run release -- -c mysuperduperconfig.json\n```\n\n\u003e By default, the release script looks for `.releaseconfig.json`\n\n#### Load extra plugins (`--plugins` or `-p`)\n\nAn array of plugin names to be loaded. Example:\n\n```\nnpm run release -- -p iobroker lerna\n```\n\n#### Print extra debug information (`--verbose` or `-V`)\n\nCan help debug the release process. Example:\n\n```\nnpm run release -- -V\n```\n\n#### Answer all applicable yes/no prompts with yes (`--yes` or `-y`)\n\nExample:\n\n```\nnpm run release minor -- --yes\n```\n\n#### Publish all monorepo packages (`--publishAll`)\n\nBy default, only changed packages of monorepos are bumped and published. With this flag, all non-private packages are re-published under a new version, even if they had no changes.\n\n## Monorepo support\n\nYou can version monorepos in two different ways.\n\n### Using the `yarn` package manager\n\n_**Note:** If possible, prefer this way. Lerna does not support some advanced Yarn features, like `workspace:*` dependency ranges._\n\nStarting with `yarn v3.1.0`, the release script can use Yarn plugins to manage versions and releases of monorepos. These plugins can be installed in your repository as follows:\n\n```bash\nyarn plugin import workspace-tools\nyarn plugin import version\nyarn plugin import https://github.com/Dcard/yarn-plugins/releases/latest/download/plugin-changed.js\n```\n\nYou also need to make sure that there is a `\"version\"` field in the root `package.json` file.\n\nTo release changed packages, simply run the following command after bumping the versions (ideally during your CI build). This assumes that the root workspace is private and should not be published:\n\n```bash\n# without dist-tags\nyarn workspaces foreach -vti --no-private npm publish --tolerate-republish\n# with dist-tags\nyarn workspaces foreach -vti --no-private npm publish --tolerate-republish --tag my-tag\n```\n\n### Using `lerna`\n\nSet up [`lerna`](https://github.com/lerna/lerna) in fixed versioning mode and install and enable the `lerna` plugin (see below). Note that this disables the use of `yarn` plugins.\n\n## Plugins\n\nSince version 3, the release script is separated into several plugins, making it easy to extend it with custom checks. The following plugins are installed and loaded by default and don't need to be installed separately:\n\n| Plugin name | Description                                            |\n| ----------- | ------------------------------------------------------ |\n| `changelog` | Parse and update the changelog                         |\n| `exec`      | Run custom scripts during the release lifecycle        |\n| `git`       | Check git status, make commits and push                |\n| `package`   | Check and update `package.json`, synchronize lockfiles |\n| `version`   | Determine the version bump                             |\n\nIf you need some of these plugins, you have to install and load them separately:\n\n| Plugin name     | Description                                                                        |\n| --------------- | ---------------------------------------------------------------------------------- |\n| `iobroker`      | Update ioBroker's `io-package.json`                                                |\n| `lerna`         | Monorepo support with `lerna`                                                      |\n| `license`       | Check for outdated years in license files                                          |\n| `manual-review` | Asks you to review the changes before committing and lets you do additional edits. |\n\nTo do so, add them as a `devDependency`:\n\n```jsonc\n// package.json\n// ...\n  \"devDependencies\": {\n    \"@alcalzone/release-script\": \"3.0.0\",\n    \"@alcalzone/release-script-plugin-iobroker\": \"3.0.0\",\n    \"@alcalzone/release-script-plugin-license\": \"3.0.0\",\n    // ... others ...\n  }\n```\n\nand add the plugin(s) to your CLI command\n\n```\nnpm run release -- -p iobroker license \u003cother options\u003e\n```\n\nor to `.releaseconfig.json` if you're using that:\n\n```jsonc\n{\n\t// ... other options\n\t\"plugins\": [\"iobroker\", \"license\"]\n}\n```\n\nIf possible, the version for the plugins should be the same as the one for `@alcalzone/release-script`.\n\n### Stages\n\nThe release process is separated into stages. By default, the following stages are active:\n\n```\ncheck → edit → commit → push → cleanup\n```\n\nbut each plugin can define its own stages.\n\n### `git` plugin options\n\n#### Include other changes in the release commit (`--includeUnstaged` or `--all`)\n\nAlthough the release commit should only include the changes relevant to the version increase, sometimes it makes sense to include other changes in the release commit. For this purpose, you can use the `--all` option, e.g.:\n\n```bash\nnpm run release patch -- --all\n```\n\n#### Using a different remote (`--remote` or `-r`)\n\nBy default, the release script pushes to the remote the current branch points to. If you want to specify a different one, you can use this flag.\nMake sure to use the complete remote branch name:\n\n```bash\nnpm run release patch -- -r upstream/master\n```\n\n#### Only push the release tag (`--tagOnly`)\n\nWhen this option is set, only the annotated release tag will be pushed to the remote. The temporary commit on the release branch will be removed afterwards. This option can be useful if branch protection rules prevent the release branch from being pushed.\n\n```bash\nnpm run release patch -- --tagOnly\n```\n\n#### Do not push to the remote at all (`--noPush`)\n\nWhen this option is set, nothing will be pushed to the remote. This option can be useful if branch protection rules prevent the release branch from being pushed, and release commits are pushed by other means.\n\n```bash\nnpm run release patch -- --noPush\n```\n\n### `changelog` plugin options\n\n#### Limit the number of entries in README.md (`--numChangelogEntries` or `-n`)\n\nOnly applies when the changelog is in `README.md` and a `CHANGELOG_OLD.md` exists. By default the most recent 5 entries are kept in `README.md`.\n\n#### Add a new placeholder after a successful release (`--addPlaceholder`)\n\nIf you want the release script to add a new empty placeholder to the changelog after a release, this option is for you. By default, this is disabled.\n\n### `package` plugin options\n\n#### Don't synchronize the lockfile (`--no-update-lockfile`)\n\nAfter bumping the version, the lockfile is normally synchronized with `package.json` to avoid errors on CI. If this is not desirable, you can disable the behavior.\n\n#### Pass the `--force` flag to the package manager when updating the lockfile (`--force-update-lockfile` or `-lf`)\n\nIn some cases it is necessary to pass the `--force` flag to the package manager when updating the lockfile. This can be done with this option. Depending on the package manager in use, this option may or may not do anything.\n\n### `version` plugin options\n\n#### Replace the version in additional files (`--versionFiles`)\n\nTo replace the version in additional files, you can use the `--versionFiles` option. It is recommended to define it via a configuration file. The option expects an array of tuples containing glob patterns to match files and one or more regular expressions to match the version to be replaced.\n\n\u003e In order for this to work, the regular expressions must surround the version to replace with lookbehind `(?\u003c=BEFORE_VERSION)` and lookahead `(?=AFTER_VERSION)` assertions. Additional backslashes are needed to escape the special characters because of JSON.\n\n\u003c!-- prettier-ignore --\u003e\n```jsonc\n{\n\t\"versionFiles\": [\n\t\t// Match `\u003eVersion: VERSION\u003c` in html files in the widget folder\n\t\t// and replace VERSION with the new version\n\t\t[\"widget/*.html\", \"(?\u003c=\\\\\u003eVersion: )(.*?)(?=\u003c)\"],\n\t\t// Check all files in the template folder and its subdirectories\n\t\t[\"templates/**/*.*\", [\n\t\t\t// Match `\"version\": \"VERSION\",` and replace VERSION with the new version\n\t\t\t\"(?\u003c=\\\"version\\\": \\\")(.*?)(?=\\\",)\",\n\t\t\t// Match `Version: \"VERSION\"` and replace VERSION with the new version\n\t\t\t\"(?\u003c=Version: \\\")(.*?)(?=\\\")\"\n\t\t]]\n  ]\n}\n```\n\n### `exec` plugin options\n\n#### Run scripts during release lifecycle (`--exec` or `-x`)\n\nTo run custom scripts, you can use these options. They accept an object defining the stage in/after/before which scripts should be executed. To execute multiple commands in sequence, you can also use an array of strings. Example:\n\n```jsonc\n{\n\t\"exec\": {\n\t\t// Run \"echo Hello\" in the \"commit\" stage\n\t\t\"commit\": \"echo Hello\",\n\t\t// Run \"echo 1\", \"echo 2\", \"echo 3\" after the \"push\" stage\n\t\t\"after_push\": [\"echo 1\", \"echo 2\", \"echo 3\"],\n\t\t// Run \"sudo shutdown\" before the \"check\" stage\n\t\t\"before_check\": \"sudo shutdown\"\n\t}\n}\n```\n\nYou can also define these on the command line (if you really must):\n\n```\nnpm run release -- -x.commit \"echo Hello\" -x.after_push \"echo 1\" \"echo 2\" \"echo 3\" -x.before_check \"sudo shutdown\"\n```\n\n### `ioBroker` plugin options\n\n#### Change where `io-package.json` is found (`--ioPackage` or `-io`)\n\nThe release script expects `io-package.json` in the package root. If that is not the case, for example if you're building a monorepo, you can change that path:\n\n```bash\nnpm run release patch -- -io packages/js-controller\n```\n\n#### Avoid prerelease versions in `io-package.json` (`--ioPackageNoPrerelease`)\n\nUsually, the version in `io-package.json` and `package.json` must match and the script will raise an error if they don't.\n\n```jsonc\n// package.json:\n\"version\": \"1.2.4\",\n\n// io-package.json:\n\"common\": {\n  \"version\": \"1.2.3\" // not OK ❌\n  // ...\n}\n```\n\nHowever, if you don't want to put a prerelease version like `v1.2.3-alpha.0-abcdefg` in `io-package.json`, you can enable this flag:\n\n```bash\nnpm run release patch -- --ioPackageNoPrerelease\n```\n\nIn this case, only the major/minor/patch part is used for `io-package.json`:\n\n```jsonc\n// package.json:\n\"version\": \"1.2.3-alpha.0-abcdefg\",\n\n// io-package.json:\n\"common\": {\n  \"version\": \"1.2.3\" // OK ✔\n  // ...\n}\n```\n\n#### Skip the release workflow check\n\nThe release script tries to find common errors in the ioBroker Github Actions release workflow file. If the check results in a false positive, you can disable this check with the `--no-workflow-check` option.\n\n```bash\nnpm run release patch -- --no-workflow-check\n```\n\n#### Limit the number of news in `io-package.json` (`--numNews` or `--nn`)\n\nBy default the most recent 7 news entries are kept in `io-package.json`. Using this option, you can change the limit.\n\n### `license` plugin options\n\n#### Change where to look for license files to check (`--license`)\n\nBy default, the files `LICENSE`, `README` with and without `.md` extension are checked (glob `\"{LICENSE,README}{,.md}\"`). Using this option, you can define an array of glob patterns to change the search paths.\n\n```bash\nnpm run release patch -- --license \"**/LICENSE\" \"packages/*/README.md\"\n```\n\n### `manual-review` plugin options\n\n_none_\n\n## Workflow file for automatic release\n\nWhen using Github Actions, you can enable automatic release on `npm` and `Github Releases` after a tagged build was successful. To do so, include the following job in your workflow definition file (e.g. `.github/workflows/test-and-release.yml`) and configure it to depend on the build jobs (here, they are called `unit-tests`).\nThe workflow must be configured to run when tags are pushed.\n\nFurthermore, you need to create a token in your npm account and add it to your repository secrets with the name `NPM_TOKEN`.\n\n\u003c!-- prettier-ignore --\u003e\n```yml\n# Run this workflow on all pushes and pull requests\n# as well as tags with a semantic version\non:\n  push:\n    # Configure your tested branches here, I like to check all of them. You can leave this out if you only want to deploy\n    branches:\n      - \"*\"\n    # You MUST limit tags to ones that are compatible with the version scheme this script uses. DO NOT include any others or they will be released aswell\n    tags:\n      # normal versions\n      - \"v[0-9]+.[0-9]+.[0-9]+\"\n      # pre-releases\n      - \"v[0-9]+.[0-9]+.[0-9]+-**\"\n  # This runs the workflow for all pull requests. You can leave this out if you only want to deploy\n  pull_request: {}\n\njobs:\n  #\n  # ... your other jobs go here ...\n  #\n\n  # Deploys the final package to NPM and Github Actions\n  deploy:\n    # Trigger this step only when a commit on master is tagged with a version number\n    if: |\n      contains(github.event.head_commit.message, '[skip ci]') == false \u0026\u0026\n      github.event_name == 'push' \u0026\u0026\n      startsWith(github.ref, 'refs/tags/v')\n\n    # Define which jobst must succeed before the release\n    needs: [unit-tests]\n\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        node-version: [14.x]\n\n    steps:\n      - name: Checkout code\n        uses: actions/checkout@v2\n\n      - name: Use Node.js ${{ matrix.node-version }}\n        uses: actions/setup-node@v1\n        with:\n          node-version: ${{ matrix.node-version }}\n\n      - name: Extract the version and commit body from the tag\n        id: extract_release\n        # The body may be multiline, therefore we need to escape some characters\n        run: |\n          VERSION=\"${{ github.ref }}\"\n          VERSION=${VERSION##*/v}\n          echo \"::set-output name=VERSION::$VERSION\"\n          BODY=$(git show -s --format=%b)\n          BODY=\"${BODY//'%'/'%25'}\"\n          BODY=\"${BODY//$'\\n'/'%0A'}\"\n          BODY=\"${BODY//$'\\r'/'%0D'}\"\n          echo \"::set-output name=BODY::$BODY\"\n\n      # If you are using TypeScript, additional build steps might be necessary\n      # Run them here, e.g.:\n      # - name: Install dependencies\n      #   run: npm ci\n      # - name: Create a clean build\n      #   run: npx gulp build\n\n      # How to release packages to npm depends on the package type.\n      # Choose one of these possibilities and or comment out the others:\n      # a) For normal packages (no monorepo):\n      - name: Publish package to npm\n        run: |\n          npm config set //registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}\n          npm whoami\n          npm publish\n      # b) For monorepos managed with lerna (requires lerna to be installed globally)\n      - name: Publish packages to npm\n        run: |\n          npm config set //registry.npmjs.org/:_authToken=${{ secrets.NPM_TOKEN }}\n          npm whoami\n          lerna publish from-package --yes\n      # c) For monorepos managed with yarn v3.1+ (no lerna)\n      - name: Publish packages to npm\n        run: |\n          yarn config set npmAuthToken \"${{ secrets.NPM_TOKEN }}\"\n          yarn npm whoami\n          yarn workspaces foreach -vti --no-private npm publish --tolerate-republish\n\n      - name: Create Github Release\n        uses: actions/create-release@v1\n        env:\n          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n        with:\n          tag_name: ${{ github.ref }}\n          release_name: Release v${{ steps.extract_release.outputs.VERSION }}\n          draft: false\n          # Prerelease versions create prereleases on Github\n          prerelease: ${{ contains(steps.extract_release.outputs.VERSION, '-') }}\n          body: ${{ steps.extract_release.outputs.BODY }}\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falcalzone%2Frelease-script","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Falcalzone%2Frelease-script","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Falcalzone%2Frelease-script/lists"}