fix(npm-plugin): upgraded to the stable version

fix(npm-plugin): upgraded to the latest beta version
Merge pull request #2332 from semantic-release/beta
2022-01-17 23:26:02 -06:00 · 2022-01-17 20:16:08 -06:00 · 2022-01-17 19:50:06 -06:00 · 2022-01-17 12:52:51 -06:00 · 2022-01-17 11:17:27 -06:00 · 2022-01-07 17:28:12 +00:00
53 changed files with 28517 additions and 436 deletions
@@ -0,0 +1,23 @@
+name: Release
+"on":
+  push:
+    branches:
+      - master
+      - next
+      - beta
+      - "*.x"
+jobs:
+  release:
+    name: release
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2
+        with:
+          cache: npm
+          node-version: 16
+      - run: npm ci
+      - run: npx semantic-release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.SEMANTIC_RELEASE_BOT_NPM_TOKEN }}
@@ -0,0 +1,52 @@
+name: Test
+
+on:
+  push:
+    branches:
+      - master
+      # renovate/** branches are generated by https://github.com/apps/renovate
+      - renovate/**
+
+  pull_request:
+    types:
+      - opened
+      - synchronize
+
+jobs:
+  test_matrix:
+    strategy:
+      matrix:
+        node-version:
+          - 14.17
+          - 16.0.0
+          - 17
+
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v2
+      - run: git config --global user.name github-actions
+      - run: git config --global user.email github-actions@github.com
+      - name: Use Node.js ${{ matrix.node-version }}
+        uses: actions/setup-node@v2
+        with:
+          node-version: ${{ matrix.node-version }}
+          cache: npm
+      - run: npm ci
+      - run: npm run test:ci
+
+  # separate job to set as required in branch protection,
+  # as the build names above change each time Node versions change
+  test:
+    runs-on: ubuntu-latest
+    needs: test_matrix
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2
+        with:
+          node-version: 16
+          cache: npm
+      - run: npm ci
+      - name: Ensure dependencies are compatible with the version of node
+        run: npx ls-engines@0.4
+      - run: npm run lint
@@ -125,10 +125,6 @@ $RECYCLE.BIN/
 # Windows shortcuts
 *.lnk

-# Lockfiles
-package-lock.json
-yarn.lock
-
 # Gitbook
 _book

@@ -1 +0,0 @@
-package-lock=false
@@ -1,11 +0,0 @@
-version: ~> 1.0
-
-services:
-  - docker
-
-import:
-  - .travis/node.yml
-  - .travis/node-versions.yml
-  - .travis/semantic-release.yml
-  - .travis/greenkeeper.yml
-  - .travis/codecov.yml
@@ -1,2 +0,0 @@
-after_success:
-  - npm run codecov
@@ -1,3 +0,0 @@
-branches:
-  only:
-    - /^greenkeeper.*$/
@@ -1,3 +0,0 @@
-node_js:
-  - 12
-  - 10.18
@@ -1,11 +0,0 @@
-language: node_js
-
-cache:
-  npm: false
-
-# Retry install on fail to avoid failing a build on network/disk/external errors
-install:
-  - travis_retry npm install
-
-script:
-  - npm run test
@@ -1,15 +0,0 @@
-branches:
-  only:
-    - master
-    - next
-    - beta
-    - /^\d+\.(\d+|x)(\.x)?$/
-
-jobs:
-  include:
-    - stage: release
-      node_js: lts/*
-      install:
-        - travis_retry npm install
-      script:
-        - npm run semantic-release
@@ -1 +0,0 @@
--install.no-lockfile true
@@ -20,45 +20,55 @@ Help us keep **semantic-release** open and inclusive. Please read and follow our

 ### Improve documentation

-As a **semantic-release** user, you are the perfect candidate to help us improve our documentation: typo corrections, clarifications, more examples, new [recipes](docs/recipes/README.md), etc. Take a look at the [documentation issues that need help](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3A%22help+wanted%22+label%3Adocs+).
+As a **semantic-release** user, you are the perfect candidate to help us improve our documentation: typo corrections, clarifications, more examples, new [recipes](docs/recipes), etc. Take a look at the [documentation issues that need help](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3A%22help+wanted%22+label%3Adocs+).

 Please follow the [Documentation guidelines](#documentation).

 ### Give feedback on issues

-Some issues are created without information requested in the [Bug report guideline](#bug-report). Help make them easier to resolve by adding any relevant information.
+Some issues are created without information requested in the [Bug report guideline](#bug-report).
+Help make them easier to resolve by adding any relevant information.

-Issues with the [design label](https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3Adesign) are meant to discuss the implementation of new features. Participating in the discussion is a good opportunity to get involved and influence the future direction of **semantic-release**.
+Issues with the [design label](https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3Adesign) are meant to discuss the implementation of new features.
+Participating in the discussion is a good opportunity to get involved and influence the future direction of **semantic-release**.

 ### Fix bugs and implement features

-Confirmed bugs and ready-to-implement features are marked with the [help wanted label](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3A%22help+wanted%22). Post a comment on an issue to indicate you would like to work on it and to request help from the [@semantic-release/maintainers](https://github.com/orgs/semantic-release/teams/contributors) and the community.
+Confirmed bugs and ready-to-implement features are marked with the [help wanted label](https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+user%3Asemantic-release+archived%3Afalse+label%3A%22help+wanted%22).
+Post a comment on an issue to indicate you would like to work on it and to request help from the [@semantic-release/maintainers](https://github.com/orgs/semantic-release/teams/contributors) and the community.

 ## Using the issue tracker

-The issue tracker is the channel for [bug reports](#bug-report), [features requests](#feature-request) and [submitting pull requests](#submitting-a-pull-request) only. Please use the [Support](docs/support/README.md) and [Get help](README.md#get-help) sections for support, troubleshooting and questions.
+The issue tracker is the channel for [bug reports](#bug-report), [features requests](#feature-request) and [submitting pull requests](#submitting-a-pull-request) only.
+Please use the [Support](docs/support/README.md) and [Get help](README.md#get-help) sections for support, troubleshooting and questions.

 Before opening an issue or a Pull Request, please use the [GitHub issue search](https://github.com/issues?utf8=%E2%9C%93&q=user%3Asemantic-release) to make sure the bug or feature request hasn't been already reported or fixed.

 ### Bug report

-A good bug report shouldn't leave others needing to chase you for more information. Please try to be as detailed as possible in your report and fill the information requested in the [Bug report template](https://github.com/semantic-release/semantic-release/issues/new?template=bug-report.md).
+A good bug report shouldn't leave others needing to chase you for more information.
+Please try to be as detailed as possible in your report and fill the information requested in the [bug report template](https://github.com/semantic-release/semantic-release/issues/new?template=01_bug_report.md).

 ### Feature request

-Feature requests are welcome, but take a moment to find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. Please provide as much detail and context as possible and fill the information requested in the [Feature request template](https://github.com/semantic-release/semantic-release/issues/new?template=feature-request.md).
+Feature requests are welcome, but take a moment to find out whether your idea fits with the scope and aims of the project.
+It's up to you to make a strong case to convince the project's developers of the merits of this feature.
+Please provide as much detail and context as possible and fill the information requested in the [feature request template](https://github.com/semantic-release/semantic-release/issues/new?template=02_feature_request.md).

 ### New plugin request

-[Plugins](docs/usage/plugins.md) are a great way to extend **semantic-release** capabilities, integrate with other systems and support new project type. Please provide as much detail and context as possible and fill the information requested in the [New plugin request template](https://github.com/semantic-release/semantic-release/issues/new?template=plugin-request.md).
+[Plugins](docs/usage/plugins.md) are a great way to extend **semantic-release** capabilities, integrate with other systems and support new project type.
+Please provide as much detail and context as possible and fill the information requested in the [plugin suggestion template](https://github.com/semantic-release/semantic-release/issues/new?template=03_plugin_suggestion.md).

 ## Submitting a Pull Request

-Good pull requests, whether patches, improvements, or new features, are a fantastic help. They should remain focused in scope and avoid containing unrelated commits.
+Good pull requests, whether patches, improvements, or new features, are a fantastic help.
+They should remain focused in scope and avoid containing unrelated commits.

-**Please ask first** before embarking on any significant pull requests (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
+**Please ask first** before embarking on any significant pull requests (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's maintainers might not want to merge into the project.

-If you have never created a pull request before, welcome 🎉 😄. [Here is a great tutorial](https://opensource.guide/how-to-contribute/#opening-a-pull-request) on how to send one :)
+If you have never created a pull request before, welcome 🎉 😄.
+[Here is a great tutorial](https://opensource.guide/how-to-contribute/#opening-a-pull-request) on how to send one :)

 Here is a summary of the steps to follow:

@@ -83,7 +93,9 @@ $ git push origin <topic-branch-name>

 **Tips**:
 - For ambitious tasks, open a Pull Request as soon as possible with the `[WIP]` prefix in the title, in order to get feedback and help from the community.
- [Allow semantic-release maintainers to make changes to your Pull Request branch](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork). This way, we can rebase it and make some minor changes if necessary. All changes we make will be done in new commit and we'll ask for your approval before merging them.
+- [Allow semantic-release maintainers to make changes to your Pull Request branch](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork).
+  This way, we can rebase it and make some minor changes if necessary.
+  All changes we make will be done in new commit, and we'll ask for your approval before merging them.

 ## Coding rules

@@ -129,7 +141,8 @@ A complex feature can be broken down into multiple commits as long as each one m

 #### Commit message format

-Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
+Each commit message consists of a **header**, a **body** and a **footer**.
+The header has a special format that includes a **type**, a **scope** and a **subject**:

 ```commit
 <type>(<scope>): <subject>
@@ -145,7 +158,8 @@ The **footer** can contain a [closing reference to an issue](https://help.github

 #### Revert

-If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
+If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit.
+In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.

 #### Type

@@ -178,7 +192,8 @@ The body should include the motivation for the change and contrast this with pre
 #### Footer
 The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**.

-**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
+**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
+The rest of the commit message is then used for this.

 #### Examples

@@ -219,7 +234,8 @@ $ npm install

 ### Lint

-All the [semantic-release](https://github.com/semantic-release) repositories use [XO](https://github.com/sindresorhus/xo) for linting and [Prettier](https://prettier.io) for formatting. Prettier formatting will be automatically verified and fixed by XO.
+All the [semantic-release](https://github.com/semantic-release) repositories use [XO](https://github.com/sindresorhus/xo) for linting and [Prettier](https://prettier.io) for formatting.
+Prettier formatting will be automatically verified and fixed by XO.

 Before pushing your code changes make sure there are no linting errors with `npm run lint`.

@@ -1,20 +1,14 @@
 <h1 align="center" style="border-bottom: none;">📦🚀 semantic-release</h1>
 <h3 align="center">Fully automated version management and package publishing</h3>
 <p align="center">
-  <a href="https://spectrum.chat/semantic-release">
-    <img alt="Join the community on Spectrum" src="https://withspectrum.github.io/badge/badge.svg">
+  <a href="https://github.com/semantic-release/semantic-release/discussions">
+    <img alt="Join the community on GitHub Discussions" src="https://img.shields.io/badge/Join%20the%20community-on%20GitHub%20Discussions-blue">
  </a>
-  <a href="https://travis-ci.org/semantic-release/semantic-release">
-    <img alt="Travis" src="https://img.shields.io/travis/semantic-release/semantic-release/master.svg">
-  </a>
-  <a href="https://codecov.io/gh/semantic-release/semantic-release">
-    <img alt="Codecov" src="https://img.shields.io/codecov/c/github/semantic-release/semantic-release/master.svg">
-  </a>
-  <a href="https://greenkeeper.io">
-    <img alt="Greenkeeper" src="https://badges.greenkeeper.io/semantic-release/semantic-release.svg">
+  <a href="https://github.com/semantic-release/semantic-release/actions?query=workflow%3ATest+branch%3Amaster">
+    <img alt="Build states" src="https://github.com/semantic-release/semantic-release/workflows/Test/badge.svg">
  </a>
  <a href="#badge">
-    <img alt="semantic-release" src="https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg">
+    <img alt="semantic-release: angular" src="https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release">
  </a>
 </p>
 <p align="center">
@@ -29,9 +23,9 @@
  </a>
 </p>

-**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
+**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes, and publishing the package.

-This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification.
+This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification and communicating the **impact** of changes to consumers.

 > Trust us, this will change your workflow for the better. – [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)

@@ -43,48 +37,53 @@ This removes the immediate connection between human emotions and version numbers
 - Notify maintainers and users of new releases
 - Use formalized commit message convention to document changes in the codebase
 - Publish on different distribution channels (such as [npm dist-tags](https://docs.npmjs.com/cli/dist-tag)) based on git merges
- Integrate with your [continuous integration workflow](docs/recipes/README.md#ci-configurations)
+- Integrate with your [continuous integration workflow](docs/recipes/release-workflow/README.md#ci-configurations)
 - Avoid potential errors associated with manual releases
- Support any [package managers and languages](docs/recipes/README.md#package-managers-and-languages) via [plugins](docs/usage/plugins.md)
+- Support any [package managers and languages](docs/recipes/release-workflow/README.md#package-managers-and-languages) via [plugins](docs/usage/plugins.md)
 - Simple and reusable configuration via [shareable configurations](docs/usage/shareable-configurations.md)

 ## How does it work?

 ### Commit message format

-**semantic-release** uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publishes the release.
+**semantic-release** uses the commit messages to determine the consumer impact of changes in the codebase.
+Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publishes the release.

-By default **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). The commit message format can be changed with the [`preset` or `config` options](docs/usage/configuration.md#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.
+By default, **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format).
+The commit message format can be changed with the [`preset` or `config` options](docs/usage/configuration.md#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.

 Tools such as [commitizen](https://github.com/commitizen/cz-cli) or [commitlint](https://github.com/conventional-changelog/commitlint) can be used to help contributors and enforce valid commit messages.

-Here is an example of the release type that will be done based on a commit messages:
+The table below shows which commit message gets you which release type when `semantic-release` runs (using the default configuration):

 | Commit message                                                                                                                                                                                   | Release type               |
-|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------|
-| `fix(pencil): stop graphite breaking when too much pressure applied`                                                                                                                             | Patch Release              |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------- |
+| `fix(pencil): stop graphite breaking when too much pressure applied`                                                                                                                             | ~~Patch~~ Fix Release      |
 | `feat(pencil): add 'graphiteWidth' option`                                                                                                                                                       | ~~Minor~~ Feature Release  |
-| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release |
+| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release <br /> (Note that the `BREAKING CHANGE: ` token must be in the footer of the commit) |

 ### Automation with CI

-**semantic-release** is meant to be executed on the CI environment after every successful build on the release branch. This way no human is directly involved in the release process and the releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org).
+**semantic-release** is meant to be executed on the CI environment after every successful build on the release branch.
+This way no human is directly involved in the release process and the releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org).

 ### Triggering a release

-For each new commits added to one of the release branches (for example `master`, `next`, `beta`), with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.
+For each new commit added to one of the release branches (for example: `master`, `next`, `beta`), with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities.

-**semantic-release** offers various ways to control the timing, the content and the audience of published releases. See example workflows in the following recipes:
- [Using distribution channels](docs/recipes/distribution-channels.md#publishing-on-distribution-channels)
- [Maintenance releases](docs/recipes/maintenance-releases.md#publishing-maintenance-releases)
- [Pre-releases](docs/recipes/pre-releases.md#publishing-pre-releases)
+**semantic-release** offers various ways to control the timing, the content and the audience of published releases.
+See example workflows in the following recipes:
+
+- [Using distribution channels](docs/recipes/release-workflow/distribution-channels.md#publishing-on-distribution-channels)
+- [Maintenance releases](docs/recipes/release-workflow/maintenance-releases.md#publishing-maintenance-releases)
+- [Pre-releases](docs/recipes/release-workflow/pre-releases.md#publishing-pre-releases)

 ### Release steps

 After running the tests, the command `semantic-release` will execute the following steps:

 | Step              | Description                                                                                                                     |
-|-------------------|---------------------------------------------------------------------------------------------------------------------------------|
+| ----------------- | ------------------------------------------------------------------------------------------------------------------------------- |
 | Verify Conditions | Verify all the conditions to proceed with the release.                                                                          |
 | Get last release  | Obtain the commit corresponding to the last release by analyzing [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). |
 | Analyze commits   | Determine the type of release based on the commits added since the last release.                                                |
@@ -98,10 +97,11 @@ After running the tests, the command `semantic-release` will execute the followi
 ## Requirements

 In order to use **semantic-release** you need:
+
 - To host your code in a [Git repository](https://git-scm.com)
 - Use a Continuous Integration service that allows you to [securely set up credentials](docs/usage/ci-configuration.md#authentication)
- Git CLI version [2.7.1 or higher](docs/support/FAQ.md#why-does-semantic-release-require-git-version--271) installed in your Continuous Integration environment
- [Node.js](https://nodejs.org) version [10.18 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1018) installed in your Continuous Integration environment
+- A Git CLI version that meets [our version requirement](docs/support/git-version.md) installed in your Continuous Integration environment
+- A [Node.js](https://nodejs.org) version that meets [our version requirement](docs/support/node-version.md) installed in your Continuous Integration environment

 ## Documentation

@@ -117,10 +117,9 @@ In order to use **semantic-release** you need:
  - [Plugins](docs/extending/plugins-list.md)
  - [Shareable configuration](docs/extending/shareable-configurations-list.md)
 - Recipes
-  - [CI configurations](docs/recipes/README.md)
-  - [Git hosted services](docs/recipes/README.md)
-  - [Release workflow](docs/recipes/README.md)
-  - [Package managers and languages](docs/recipes/README.md)
+  - [CI configurations](docs/recipes/ci-configurations/README.md)
+  - [Git hosted services](docs/recipes/git-hosted-services/README.md)
+  - [Release workflow](docs/recipes/release-workflow/README.md)
 - Developer guide
  - [JavaScript API](docs/developer-guide/js-api.md)
  - [Plugins development](docs/developer-guide/plugin.md)
@@ -134,18 +133,19 @@ In order to use **semantic-release** you need:

 ## Get help

+- [GitHub Discussions](https://github.com/semantic-release/semantic-release/discussions)
 - [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release)
- [Spectrum community](https://spectrum.chat/semantic-release)
 - [Twitter](https://twitter.com/SemanticRelease)

 ## Badge

-Let people know that your package is published using **semantic-release** by including this badge in your readme.
+Let people know that your package is published using **semantic-release** and which [commit-convention](#commit-message-format) is followed by including this badge in your readme.

-[![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release)
+[![semantic-release: angular](https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release)](https://github.com/semantic-release/semantic-release)

 ```md
-[![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release)
+[![semantic-release: angular](https://img.shields.io/badge/semantic--release-angular-e10079?logo=semantic-release)](https://github.com/semantic-release/semantic-release)
+
 ```

 ## Team
@@ -160,7 +160,6 @@ Let people know that your package is published using **semantic-release** by inc
 | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
 | [Stephan Bönnemann](https://github.com/boennemann)                                                | [Rolf Erik Lekang](https://github.com/relekang)                                              | [Johannes Jörg Schmidt](https://github.com/jo)                                        | [Finn Pauls](https://github.com/finnp)                                           | [Christoph Witzko](https://github.com/christophwitzko)                                                     |

-
 <p align="center">
  <img alt="Kill all humans" src="media/bender.png">
 </p>
@@ -14,13 +14,18 @@
 - [Shareable configuration](docs/extending/shareable-configurations-list.md)

 ## Recipes
- [CI configurations](docs/recipes/README.md#ci-configurations)
-	- [CircleCI 2.0](docs/recipes/circleci-workflows.md)
-	- [Travis CI](docs/recipes/travis.md)
-	- [GitLab CI](docs/recipes/gitlab-ci.md)
- [Git hosted services](docs/recipes/README.md#git-hosted-services)
-	- [Git authentication with SSH keys](docs/recipes/git-auth-ssh-keys.md)
- [Package managers and languages](docs/recipes/README.md#package-managers-and-languages)
+- [CI configurations](docs/recipes/ci-configurations/README.md)
+  - [CircleCI 2.0](docs/recipes/ci-configurations/circleci-workflows.md)
+  - [Travis CI](docs/recipes/ci-configurations/travis.md)
+  - [GitLab CI](docs/recipes/ci-configurations/gitlab-ci.md)
+  - [GitHub Actions](docs/recipes/ci-configurations/github-actions.md)
+  - [Jenkins CI](docs/recipes/ci-configurations/jenkins-ci.md)
+- [Git hosted services](docs/recipes/git-hosted-services/README.md)
+  - [Git authentication with SSH keys](docs/recipes/git-hosted-services/git-auth-ssh-keys.md)
+- [Release Workflow](docs/recipes/release-workflow/README.md)
+  - [Publishing on distribution channels](docs/recipes/release-workflow/distribution-channels.md)
+  - [Publishing maintenance releases](docs/recipes/release-workflow/maintenance-releases.md)
+  - [Publishing pre-releases](docs/recipes/release-workflow/pre-releases.md)

 ## Developer guide
 - [JavaScript API](docs/developer-guide/js-api.md)
@@ -33,3 +38,4 @@
 - [Troubleshooting](docs/support/troubleshooting.md)
 - [Node version requirement](docs/support/node-version.md)
 - [Node Support Policy](docs/support/node-support-policy.md)
+- [Git version requirement](docs/support/git-version.md)
@@ -1,7 +1,7 @@
 # semantic-release documentation

 - [Usage](usage/README.md) - **semantic-release** installation and configuration
- [Extending](extending/README.md)- Extending **semantic-release** with plugins and shareable configurations
- [Recipes](recipes/README.md) - Community written recipes for common **semantic-release** use-cases
+- [Extending](extending/README.md) - Extending **semantic-release** with plugins and shareable configurations
+- [Recipes](recipes/release-workflow/README.md) - Community written recipes for common **semantic-release** use-cases
 - [Developer Guide](developer-guide/README.md) - The essentials of writing a **semantic-release** plugin or shareable configurations
 - [Support](support/README.md) - FAQ and troubleshooting
@@ -1,14 +1,18 @@
 # Plugin Developer Guide

-To create a plugin for `semantic-release`, you need to decide which parts of the release lifecycle are important to that plugin. For example, it is best to always have a `verify` step because you may be receiving inputs from a user and want to make sure they exist. A plugin can abide by any of the following lifecycles:
+To create a plugin for `semantic-release`, you need to decide which parts of the release lifecycle are important to that plugin. For example, it is best to always have a `verifyConditions` step because you may be receiving inputs from a user and want to make sure they exist. A plugin can abide by any of the following lifecycles:

- `verify`
+- `verifyConditions`
+- `analyzeCommits`
+- `verifyRelease`
+- `generateNotes`
+- `addChannel`
 - `prepare`
 - `publish`
 - `success`
 - `fail`

-`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a `verify` and `success` step, the `main` file for your object would need to `export` an object with `verify` and `success` functions.
+`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.

 In addition to the lifecycle methods, each lifecyle is passed two objects:

@@ -30,7 +34,7 @@ We recommend you setup a linting system to ensure good javascript practices are
 In your `index.js` file, you can start by writing the following code

 ```javascript
-const verifyConditions = require('./src/verify');
+const verify = require('./src/verify');

 let verified;

@@ -39,12 +43,12 @@ let verified;
 * @param {*} pluginConfig The semantic-release plugin config
 * @param {*} context The context provided by semantic-release
 */
-async function verify(pluginConfig, context) {
-  await verifyConditions(pluginConfig, context);
+async function verifyConditions(pluginConfig, context) {
+  await verify(pluginConfig, context);
  verified = true;
 }

-module.exports = { verify };
+module.exports = { verifyConditions };
 ```

 Then, in your `src` folder, create a file called `verify.js` and add the following
@@ -93,7 +97,136 @@ if (message.length) {
 }
 ```

-## Supporting Environment Variables
+## Context
+
+### Common context keys
+
+* `stdout`
+* `stderr`
+* `logger`
+
+### Context object keys by lifecycle
+
+#### verifyConditions
+
+Initially the context object contains the following keys (`verifyConditions` lifecycle):
+* `cwd`
+  * Current working directory
+* `env`
+  * Environment variables
+* `envCi`
+  * Information about CI environment
+  * Contains (at least) the following keys:
+    * `isCi`
+      * Boolean, true if the environment is a CI environment
+    * `commit`
+      * Commit hash
+    * `branch`
+      * Current branch
+* `options`
+  * Options passed to `semantic-release` via CLI, configuration files etc.
+* `branch`
+  * Information on the current branch
+  * Object keys:
+    * `channel`
+    * `tags`
+    * `type`
+    * `name`
+    * `range`
+    * `accept`
+    * `main`
+* `branches`
+  * Information on branches
+  * List of branch objects (see above)
+
+#### analyzeCommits
+
+Compared to the verifyConditions, `analyzeCommits` lifecycle context has keys
+
+* `commits` (List)
+  * List of commits taken into account when determining the new version.
+  * Keys:
+    * `commit` (Object)
+      * Keys:
+        * `long` (String, Commit hash)
+        * `short` (String, Commit hash)
+    * `tree` (Object)
+      * Keys:
+        * `long` (String, Commit hash)
+        * `short` (String, Commit hash)
+    * `author` (Object)
+      * Keys:
+        * `name` (String)
+        * `email` (String)
+        * `date` (String, ISO 8601 timestamp)
+    * `committer` (Object)
+      * Keys:
+        * `name` (String)
+        * `email` (String)
+        * `date` (String, ISO 8601 timestamp)
+    * `subject` (String, Commit message subject)
+    * `body` (String, Commit message body)
+    * `hash` (String, Commit hash)
+    * `committerDate` (String, ISO 8601 timestamp)
+    * `message` (String)
+    * `gitTags` (String, List of git tags)
+* `releases` (List)
+* `lastRelease` (Object)
+  * Keys
+    * `version` (String)
+    * `gitTag` (String)
+    * `channels` (List)
+    * `gitHead` (String, Commit hash)
+    * `name` (String)
+
+#### verifyRelease
+
+Additional keys:
+
+* `nextRelease` (Object)
+  * `type` (String)
+  * `channel` (String)
+  * `gitHead` (String, Git hash)
+  * `version` (String, version without `v`)
+  * `gitTag` (String, version with `v`)
+  * `name` (String)
+    
+#### generateNotes
+
+No new content in the context.
+
+#### addChannel
+
+*This is run only if there are releases that have been merged from a higher branch but not added on the channel of the current branch.*
+
+Context content is similar to lifecycle `verifyRelease`.
+
+#### prepare
+
+Only change is that `generateNotes` has populated `nextRelease.notes`.
+
+#### publish
+
+No new content in the context.
+
+#### success
+
+Lifecycles `success` and `fail` are mutually exclusive, only one of them will be run.
+
+Additional keys:
+
+* `releases`
+  * Populated by `publish` lifecycle
+
+#### fail
+
+Lifecycles `success` and `fail` are mutually exclusive, only one of them will be run.
+
+Additional keys:
+
+* `errors`
+
+### Supporting Environment Variables

 Similar to `options`, environment variables exist to allow users to pass tokens and set special URLs. These are set on the `context` object instead of the `pluginConfig` object. Let's say we wanted to check for `GITHUB_TOKEN` in the environment because we want to post to GitHub on the user's behalf. To do this, we can add the following to our `verify` command:

@@ -101,6 +234,47 @@ Similar to `options`, environment variables exist to allow users to pass tokens
 const { env } = context;

 if (env.GITHUB_TOKEN) {
-    //...
+  //...
 }
-```
+```
+## Logger
+Use `context.logger` to provide debug logging in the plugin.
+
+```js
+const { logger } = context;
+
+logger.log('Some message from plugin.'). 
+```
+
+The above usage yields the following where `PLUGIN_PACKAGE_NAME` is automatically inferred.
+
+```
+[3:24:04 PM] [semantic-release] [PLUGIN_PACKAGE_NAME] › ℹ  Some message from plugin.
+```
+
+## Execution order
+
+For the lifecycles, the list at the top of the readme contains the order. If there are multiple plugins for the same lifecycle, then the order of the plugins determines the order in which they are executed.
+
+## Handling errors
+
+In order to be able to detect and handle errors properly, the errors thrown from the must be of type [SemanticReleaseError](https://github.com/semantic-release/error) or extend it as described in the package readme. This way the errors are handled properly and plugins using the `fail` lifecycle receive the errors correctly. For any other types of errors the internal error handling does nothing, lets them through up until the final catch and does not call any `fail` plugins.
+
+## Advanced
+
+Knowledge that might be useful for plugin developers.
+
+### Multiple analyzeCommits plugins
+
+While it may be trivial that multiple analyzeCommits (or any lifecycle plugins) can be defined, it is not that self-evident that the plugins executed AFTER the first one (for example, the default one: `commit-analyzer`) can change the result. This way it is possible to create more advanced rules or situations, e.g. if none of the commits would result in new release, then a default can be defined.
+
+The commit must be a known release type, for example the commit-analyzer has the following default types:
+* major
+* premajor
+* minor
+* preminor
+* patch
+* prepatch
+* prerelease
+
+If the analyzeCommits-lifecycle plugin does not return anything, then the earlier result is used, but if it returns a supported string value, then that overrides the previous result.
@@ -20,7 +20,7 @@
  - `publish`: Publish the package on the npm registry
 - [@semantic-release/gitlab](https://github.com/semantic-release/gitlab)
  - `verifyConditions`: Verify the presence and the validity of the GitLab authentication and release configuration
-  - `publish`: Publish a [GitLab release](https://docs.gitlab.com/ce/workflow/releases.html)
+  - `publish`: Publish a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/)
 - [@semantic-release/git](https://github.com/semantic-release/git)
  - `verifyConditions`: Verify the presence and the validity of the Git authentication and release configuration
  - `prepare`: Push a release commit and tag, including configurable files
@@ -52,6 +52,10 @@
 - [semantic-release-docker](https://github.com/felixfbecker/semantic-release-docker)
  - `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry.
  - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
+- [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker)
+  - `verifyConditions`: Verify that all needed configuration is present and login to the configured docker registry.
+  - `publish`: Tag the image specified by `name` with the new version and channel and push it to the configured docker registry.
+  - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry ie: next to latest.
 - [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr)
  - `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry
  - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
@@ -91,6 +95,9 @@
 - [semantic-release-github-pages](https://github.com/qiwi/semantic-release-gh-pages-plugin)
  - `verifyConditions`: Verify the presence of the auth token set via environment variables.
  - `publish`: Pushes commit to the documentation branch.
+- [semantic-release-github-pullrequest](https://github.com/asbiin/semantic-release-github-pullrequest)
+  - `verifyConditions`: Verify the presence and the validity of the GitHub authentication and other configuration.
+  - `publish`: Create a branch to upload all assets and create the pull request on the base branch on GitHub.
 - [leiningen-semantic-release](https://github.com/NoxHarmonium/leiningen-semantic-release)
  - `verifyConditions`: Checks the project.clj is syntactically valid.
  - `prepare`: Update the project.clj version and package the output jar file.
@@ -124,3 +131,29 @@
  - `verifyConditions`: Validate configuration and (if present) credentials
  - `prepare`: Update version and appVersion in ```Chart.yaml```
  - `publish`: Publish the chart to a registry (if configured)
+- [semantic-release-codeartifact](https://github.com/ryansonshine/semantic-release-codeartifact)
+  - `verifyConditions`: Validate configuration, get AWS CodeArtifact authentication and repository, validate `publishConfig` or `.npmrc` (if they exist), then pass the configuration to the associated plugins.
+- [semantic-release-telegram](https://github.com/pustovitDmytro/semantic-release-telegram)
+  - `verifyConditions`: Validate configuration and verify ```TELEGRAM_BOT_ID``` and ```TELEGRAM_BOT_TOKEN```
+  - `success`: Publish a message about the successful release to a telegram chat
+  - `fail`: publish a message about failure to a telegram chat
+- [semantic-release-heroku](https://github.com/pustovitDmytro/semantic-release-heroku)
+  - `verifyConditions`: Validate configuration and verify ```HEROKU_API_KEY```
+  - `prepare`: Update the package.json version and create release tarball
+  - `publish`: Publish version to heroku
+- [semantic-release-mattermost](https://github.com/ttrobisch/semantic-release-mattermost)
+  - `verifyConditions`: Verify that the webhook is setup and release-notes-generator is present.
+  - `success`: Send a message about the new release and its notes to a [mattermost](https://mattermost.com/) webhook.
+- [semantic-release-github-milestones](https://github.com/nitzano/semantic-release-github-milestones)
+  - `verifyConditions`: Verify github tokens are present and valid.
+  - `verifyRelease`: Display information regarding the matching github milestone.
+- [semantic-release-telegram-bot](https://github.com/skoropadas/semantic-release-telegram-bot)
+  - `verifyConditions`: Validate configuration and verify `TELEGRAM_BOT_TOKEN` and package name
+  - `success`: Publish a success message to certain telegram chats
+  - `fail`: Publish a fail message to certain telegram chats
+- [semantic-release-npm-deprecate](https://github.com/jpoehnelt/semantic-release-npm-deprecate)
+  - `publish`: Automatically mark old versions as deprecated.
+- [@eshepelyuk/semantic-release-helm-oci](https://github.com/eshepelyuk/semantic-release-helm-oci)
+  - `verifyConditions`: Verify plugin configuration and login to Helm registry
+  - `prepare`: Package Helm chart to local folder
+  - `publish`: Publish Helm chart to OCI registry
@@ -1,18 +0,0 @@
-# Recipes
-
-## CI configurations
- [CircleCI 2.0 workflows](circleci-workflows.md)
- [Travis CI](travis.md)
- [GitLab CI](gitlab-ci.md)
- [GitHub Actions](github-actions.md)
- [Jenkins CI](jenkins-ci.md)
-
-## Git hosted services
- [Git authentication with SSH keys](git-auth-ssh-keys.md)
-
-## Release workflow
- [Publishing on distribution channels](distribution-channels.md)
- [Publishing maintenance releases](maintenance-releases.md)
- [Publishing pre-releases](pre-releases.md)
-
-## Package managers and languages
@@ -0,0 +1,6 @@
+# CI configurations
+- [CircleCI 2.0 workflows](circleci-workflows.md)
+- [Travis CI](travis.md)
+- [GitLab CI](gitlab-ci.md)
+- [GitHub Actions](github-actions.md)
+- [Jenkins CI](jenkins-ci.md)
@@ -0,0 +1,51 @@
+# Using semantic-release with [CircleCI 2.0 workflows](https://circleci.com/docs/2.0/workflows)
+
+## Environment variables
+
+The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured in [CircleCi Project Settings](https://circleci.com/docs/2.0/env-vars/#adding-environment-variables-in-the-app)..
+
+Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../../usage/getting-started.md#getting-started).
+
+## Multiple Node jobs configuration
+
+### `.circleci/config.yml` configuration for multiple Node jobs
+
+This example is a minimal configuration for **semantic-release** with tests running against Node 16 and 14.
+See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
+
+In this example, the [`circleci/node`](https://circleci.com/developer/orbs/orb/circleci/node) orb is imported (Which makes some node operations easier), then a `release` job is defined which will run `semantic-release`.
+
+To run our `release` job, we have created a workflow named `test_and_release` which will run two jobs, `node/test`, which comes from the node orb and will test our application, and our release job.
+Here, we are actually making use of [matrix jobs](https://circleci.com/blog/circleci-matrix-jobs/) so that our single `node/test` job will actually be executed twice, once for Node version 16, and once for version 14.
+Finally, we call our release job with a `requires` parameter so that `release` will run against the latest LTS version of node, only after `node/test` has successfully tested against v14 and v16.
+
+```yaml
+version: 2.1
+orbs:
+  node: circleci/node@4.5
+jobs:
+  release:
+    executor: node/default
+    steps:
+      - checkout
+      - node/install
+          lts: true
+      - node/install-packages # Install and automatically cache packages
+      # Run optional required steps before releasing
+      # - run: npm run build-script
+      - run: npx semantic-release
+
+workflows:
+  test_and_release:
+    # Run the test jobs first, then the release only when all the test jobs are successful
+    jobs:
+      - node/test:
+          matrix:
+            parameters:
+              version:
+                - 16.1.0
+                - 14.17.0
+      - release:
+          requires:
+            - node/test
+```
@@ -2,7 +2,7 @@

 ## Environment variables

-The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured with [Secret Variables](https://help.github.com/en/articles/virtual-environments-for-github-actions#creating-and-using-secrets-encrypted-variables).
+The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured with [Secret Variables](https://docs.github.com/en/actions/reference/encrypted-secrets).

 In this example a publish type [`NPM_TOKEN`](https://docs.npmjs.com/creating-and-viewing-authentication-tokens) is required to publish a package to the npm registry. GitHub Actions [automatically populate](https://help.github.com/en/articles/virtual-environments-for-github-actions#github_token-secret) a [`GITHUB_TOKEN`](https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line) environment variable which can be used in Workflows.

@@ -10,11 +10,12 @@ In this example a publish type [`NPM_TOKEN`](https://docs.npmjs.com/creating-and

 [GitHub Actions](https://github.com/features/actions) support [Workflows](https://help.github.com/en/articles/configuring-workflows), allowing to run tests on multiple Node versions and publish a release only when all test pass.

-**Note**: The publish pipeline must run on [Node version >= 10.18](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
+**Note**: The publish pipeline must run on a [Node version that meets our version requirement](../../support/node-version.md).

 ### `.github/workflows/release.yml` configuration for Node projects

-The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on Node 12 when a new commit is pushed to a `master` branch. See [Configuring a Workflow](https://help.github.com/en/articles/configuring-a-workflow) for additional configuration options.
+The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on the latest LTS version of Node when a new commit is pushed to a `master` branch.
+See [Configuring a Workflow](https://help.github.com/en/articles/configuring-a-workflow) for additional configuration options.

 ```yaml
 name: Release
@@ -25,16 +26,16 @@ on:
 jobs:
  release:
    name: Release
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Setup Node.js
-        uses: actions/setup-node@v1
+        uses: actions/setup-node@v2
        with:
-          node-version: 12
+          node-version: 'lts/*'
      - name: Install dependencies
        run: npm ci
      - name: Release
@@ -2,7 +2,7 @@

 ## Environment variables

-The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured with [Protected variables](https://docs.gitlab.com/ce/ci/variables/README.html#protected-environment-variables).
+The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured with [Protected variables](https://docs.gitlab.com/ce/ci/variables/README.html#protected-environment-variables).

 **Note**: Make sure to configure your release branch as [protected](https://docs.gitlab.com/ce/user/project/protected_branches.html) in order for the CI/CD build to access the protected variables.

@@ -10,13 +10,13 @@ The [Authentication](../usage/ci-configuration.md#authentication) environment va

 GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) allowing to test on multiple Node versions and publishing a release only when all test pass.

-**Note**: The publish pipeline must run a [Node >= 10.18 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
+**Note**: The publish pipeline must run a [Node version that meets our version requirement](../../support/node-version.md).

 ### `.gitlab-ci.yml` configuration for Node projects

 This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.

-**Note**: The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
+**Note**: The`semantic-release` execution command varies depending on whether you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.

 ```yaml
 # The release pipeline will run only if all jobs in the test pipeline are successful
@@ -50,11 +50,11 @@ publish:

 This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.

-**Note**: The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
+**Note**: The`semantic-release` execution command varies depending if you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.


 ```yaml
-# The release pipeline will run only on the master branch a commit is triggered 
+# The release pipeline will run only on the master branch a commit is triggered
 stages:
  - release

@@ -83,7 +83,7 @@ release:

 ### `package.json` configuration

-A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
+A `package.json` is required only for [local](../../usage/installation.md#local-installation) **semantic-release** installation.

 ```json
 {
@@ -2,24 +2,24 @@

 ## Environment variables

-The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured in [Jenkins Project Settings](https://www.jenkins.io/doc/pipeline/tour/environment/)..
+The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured in [Jenkins Project Settings](https://www.jenkins.io/doc/pipeline/tour/environment/)..

-Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../usage/getting-started.md#getting-started).
+Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../../usage/getting-started.md#getting-started).

 ## Node.js project configuration

 ### `Jenkinsfile (Declarative Pipeline)` configuration for a Node.js job

-**Note**: The publish pipeline must run a [Node >= 10.18 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
+**Note**: The publish pipeline must run a Node version that [meets our requirement](../../support/node-version.md).

-This example is a minimal configuration for **semantic-release** with a build running Node 10.18. See [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.
-
-The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
+This example is a minimal configuration for **semantic-release** with a build running a version of Node labelled as "node LTS".
+Since versions of Node are manually downloaded and labelled, we recommend keeping the version used for the release steps up-to-date with the latest LTS version.
+See the [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.

 ```yaml
 // The release stage in the pipeline will run only if the test stage in the pipeline is successful
 pipeline {
-    agent any 
+    agent any
    environment {
        GH_TOKEN  = credentials('some-id')
    }
@@ -31,18 +31,18 @@ pipeline {
                npm install
                npm test
                '''
-                }
+            }
        }
        stage('Release') {
            tools {
-            nodejs "node 10.18"
+                nodejs "node LTS"
            }
            steps {
                sh '''
                # Run optional required steps before releasing
                npx semantic-release
                '''
-            }            
+            }
        }
    }
 }
@@ -50,12 +50,12 @@ pipeline {

 ### `package.json` configuration for a Node job

-A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
+A `package.json` is required only for [local](../../usage/installation.md#local-installation) **semantic-release** installation.

 ```json
 {
  "devDependencies": {
-    "semantic-release": "^15.0.0"
+    "semantic-release": "^18.0.0"
  }
 }
-```
+```
@@ -2,17 +2,17 @@

 ## Environment variables

-The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured in [Travis Repository Settings](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-Settings) or with the [travis env set CLI](https://github.com/travis-ci/travis.rb#env).
+The [Authentication](../../usage/ci-configuration.md#authentication) environment variables can be configured in [Travis Repository Settings](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-Settings) or with the [travis env set CLI](https://github.com/travis-ci/travis.rb#env).

-Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../usage/getting-started.md#getting-started).
+Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../../usage/getting-started.md#getting-started).

 ## Node.js projects configuration

 ### `.travis.yml` configuration for multiple Node.js jobs

-This example is a minimal configuration for **semantic-release** with a build running Node 6 and 8. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 14 and 16. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.

-This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
+This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).

 It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification.

@@ -24,8 +24,8 @@ It's recommended to run the `semantic-release` command in the [Travis `deploy` s
 language: node_js

 node_js:
-  - 8
-  - 6
+  - 14
+  - 16

 jobs:
  include:
@@ -43,12 +43,12 @@ jobs:

 ### `package.json` configuration for multiple Node jobs

-A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
+A `package.json` is required only for [local](../../usage/installation.md#local-installation) **semantic-release** installation.

 ```json
 {
  "devDependencies": {
-    "semantic-release": "^15.0.0"
+    "semantic-release": "^18.0.0"
  }
 }
 ```
@@ -57,13 +57,13 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins

 For projects that require to be tested with one or multiple version of a Non-JavaScript [language](https://docs.travis-ci.com/user/languages), optionally on multiple [Operating Systems](https://docs.travis-ci.com/user/multi-os).

-This recipe cover the Travis specifics only. See [Non JavaScript projects recipe](../support/FAQ.md#can-i-use-semantic-release-to-publish-non-javascript-packages) for more information on the **semantic-release** configuration.
+This recipe cover the Travis specifics only. See [Non JavaScript projects recipe](../../support/FAQ.md#can-i-use-semantic-release-to-publish-non-javascript-packages) for more information on the **semantic-release** configuration.

 ### `.travis.yml` configuration for non-JavaScript projects

 This example is a minimal configuration for **semantic-release** with a build running [Go 1.6 and 1.7](https://docs.travis-ci.com/user/languages/go). See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.

-This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
+This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).

 It's recommended to run the `semantic-release` command in the [Travis `deploy` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error occurs the build will fail and Travis will send a notification.

@@ -1,65 +0,0 @@
-# Using semantic-release with [CircleCI 2.0 workflows](https://circleci.com/docs/2.0/workflows)
-
-## Environment variables
-
-The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured in [CircleCi Project Settings](https://circleci.com/docs/2.0/env-vars/#adding-environment-variables-in-the-app)..
-
-Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../usage/getting-started.md#getting-started).
-
-## Multiple Node jobs configuration
-
-### `.circleci/config.yml` configuration for multiple Node jobs
-
-This example is a minimal configuration for **semantic-release** with a build running Node 6 and 8. See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
-
-This example create the workflows `test_node_4`, `test_node_6`, `test_node_8` and `release`. The release workflows will [run `semantic-release` only after the all the `test_node_*` are successful](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
-
-```yaml
-version: 2
-jobs:
-  test_node_6:
-    docker:
-      - image: circleci/node:6
-    steps:
-      # Configure your test steps here (checkout, npm install, cache management, tests etc...)
-
-  test_node_8:
-    docker:
-      - image: circleci/node:8
-    steps:
-      # Configure your test steps here (checkout, npm install, cache management, tests etc...)
-
-  release:
-    docker:
-      - image: circleci/node:8
-    steps:
-      - checkout
-      - run: npm install
-      # Run optional required steps before releasing
-      # - run: npm run build-script
-      - run: npx semantic-release
-
-workflows:
-  version: 2
-  test_and_release:
-    # Run the test jobs first, then the release only when all the test jobs are successful
-    jobs:
-      - test_node_6
-      - test_node_8
-      - release:
-          requires:
-            - test_node_6
-            - test_node_8
-```
-
-### `package.json` configuration for multiple Node jobs
-
-A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
-
-```json
-{
-  "devDependencies": {
-    "semantic-release": "^15.0.0"
-  }
-}
-```
@@ -0,0 +1,2 @@
+# Git hosted services
+- [Git authentication with SSH keys](git-auth-ssh-keys.md)
@@ -1,6 +1,6 @@
 # Git authentication with SSH keys

-When using [environment variables](../usage/ci-configuration.md#authentication) to set up the Git authentication, the remote Git repository will automatically be accessed via [https](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_http_protocols), independently of the [`repositoryUrl`](../usage/configuration.md#repositoryurl) format configured in the **semantic-release** [Configuration](../usage/configuration.md#configuration) (the format will be automatically converted as needed).
+When using [environment variables](../../usage/ci-configuration.md#authentication) to set up the Git authentication, the remote Git repository will automatically be accessed via [https](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_http_protocols), independently of the [`repositoryUrl`](../../usage/configuration.md#repositoryurl) format configured in the **semantic-release** [Configuration](../../usage/configuration.md#configuration) (the format will be automatically converted as needed).

 Alternatively the Git repository can be accessed via [SSH](https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols#_the_ssh_protocol) by creating SSH keys, adding the public one to your Git hosted account and making the private one available on the CI environment.

@@ -0,0 +1,4 @@
+# Release workflow
+- [Publishing on distribution channels](distribution-channels.md)
+- [Publishing maintenance releases](maintenance-releases.md)
+- [Publishing pre-releases](pre-releases.md)
@@ -3,8 +3,8 @@
 This recipe will walk you through a simple example that uses distribution channels to make releases available only to a subset of users, in order to collect feedbacks before distributing the release to all users.

 This example uses the **semantic-release** default configuration:
- [branches](../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
- [plugins](../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`
+- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
+- [plugins](../../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`

 ## Initial release

@@ -97,7 +97,7 @@ The Git history of the repository is now:

 After a period of feedback from our users using the `@next` dist-tag we feel confident to make our big feature available to all users. To do so we merge the `next` branch into `master`. There should be no conflict as `next` is strictly ahead of `master`.

-Once the merge commit is pushed to `next`, **semantic-release** will add the version `2.1.0` to the dist-tag `@latest` so all users will receive it when installing out module with `npm install example-module`.
+Once the merge commit is pushed to `master`, **semantic-release** will add the version `2.1.0` to the dist-tag `@latest` so all users will receive it when installing out module with `npm install example-module`.

 The Git history of the repository is now:

@@ -3,8 +3,8 @@
 This recipe will walk you through a simple example that uses Git branches and distribution channels to publish fixes and features for old versions of a package.

 This example uses the **semantic-release** default configuration:
- [branches](../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
- [plugins](../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`
+- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
+- [plugins](../../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`

 ## Initial release

@@ -18,7 +18,7 @@ The Git history of the repository is:

 ## Releasing a breaking change

-We now decide to drop Node.js 6 support for our package, and require Node.js 8 or higher, which is a breaking change.  
+We now decide to drop Node.js 6 support for our package, and require Node.js 8 or higher, which is a breaking change.

 We commit that change with the message `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required` to `master`. When pushing that commit, **semantic-release** will release the version `2.0.0` on the dist-tag `@latest`.

@@ -33,7 +33,7 @@ The Git history of the repository is now:

 One of our users request a new feature, however they cannot migrate to Node.js 8 or higher due to corporate policies.

-If we were to push that feature on `master` and release it, the new version would require Node.js 8 or higher as the release would also contains the commit `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.
+If we were to push that feature on `master` and release it, the new version would require Node.js 8 or higher as the release would also contain the commit `feat: drop Node.js 6 support \n\n BREAKING CHANGE: Node.js >= 8 required`.

 Instead, we create the branch `1.x` from the tag `v1.0.0` with the command `git checkout -b 1.x v1.0.0` and we commit that feature with the message `feat: a feature` to the branch `1.x`. When pushing that commit, **semantic-release** will release the version `1.1.0` on the dist-tag `@release-1.x` so users who can't migrate to Node.js 8 or higher can benefit from it.

@@ -48,7 +48,7 @@ The Git history of the repository is now:

 ## Releasing a bug fix for version 1.0.x users

-Another user currently using version `1.0.0` reports a bug. They cannot migrate to Node.js 8 or higher and they also cannot migrate to `1.1.0` as they do not use the feature developed in `feat: a feature` and their corporate policies require to go through a costly quality insurance process for each `minor` upgrades.
+Another user currently using version `1.0.0` reports a bug. They cannot migrate to Node.js 8 or higher and they also cannot migrate to `1.1.0` as they do not use the feature developed in `feat: a feature` and their corporate policies require to go through a costly quality assurance process for each `minor` upgrades.

 In order to deliver the bug fix in a `patch` release, we create the branch `1.0.x` from the tag `v1.0.0` with the command `git checkout -b 1.0.x v1.0.0` and we commit that fix with the message `fix: a fix` to the branch `1.0.x`. When pushing that commit, **semantic-release** will release the version `1.0.1` on the dist-tag `@release-1.0.x` so users who can't migrate to `1.1.x` or `2.x` can benefit from it.

@@ -3,8 +3,8 @@
 This recipe will walk you through a simple example that uses pre-releases to publish beta versions while working on a future major release and then make only one release on the default distribution.

 This example uses the **semantic-release** default configuration:
- [branches](../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
- [plugins](../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`
+- [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`
+- [plugins](../../usage/configuration.md#plugins): `['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/npm', '@semantic-release/github']`

 ## Initial release

@@ -38,48 +38,18 @@ If using npm hook scripts is not possible, and alternative solution is to [`@sem

 Yes with the [dry-run options](../usage/configuration.md#dryrun) which prints to the console the next version to be published and the release notes.

-## Can I use semantic-release with Yarn?
-
-If you are using a [local](../usage/installation.md#local-installation) **semantic-release** installation and run multiple CI jobs with different versions, the `yarn install` command will fail on jobs running with Node < 8 as **semantic-release** requires [Node >= 10.18](#why-does-semantic-release-require-node-version--1018) and specifies it in its `package.json`s [`engines`](https://docs.npmjs.com/files/package.json#engines) key.
-
-The recommended solution is to use the [Yarn](https://yarnpkg.com) [--ignore-engines](https://yarnpkg.com/en/docs/cli/install#toc-yarn-install-ignore-engines) option to install the project dependencies on the CI environment, so Yarn will ignore the **semantic-release**'s `engines` key:
-
-```bash
-$ yarn install --ignore-engines
-```
-
-**Note**: Several CI services use Yarn by default if your repository contains a `yarn.lock` file. So you should override the install step to specify `yarn install --ignore-engines`.
-
-Alternatively you can use a [global](../usage/installation.md#global-installation) **semantic-release** installation and make sure to install and run the `semantic-release` command only in a CI jobs running with Node >= 10.18.
-
-If your CI environment provides [nvm](https://github.com/creationix/nvm) you can switch to Node 8 before installing and running the `semantic-release` command:
-
-```bash
-$ nvm install 8 && yarn global add semantic-release && semantic-release
-```
-
-See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
-
-As `semantic-release` is recommended to be executed with [`npx`](https://www.npmjs.com/package/npx) an alternative is required for usage with Yarn. Even though it is possible to install npx with Yarn, it's not recommended. Yarn and npx would be using different cache locations.
-
-For [local installation](../usage/installation.md#local-installation) replace
-`npx semantic-release` with `yarn run semantic-release`.
-
-For [global installation](../usage/installation.md#global-installation) replace
-`npx semantic-release` with `yarn global add semantic-release && semantic-release`.
-
 ## Can I use semantic-release to publish non-JavaScript packages?

-Yes, **semantic-release** is a Node CLI application but it can be used to publish any type of packages.
+Yes, **semantic-release** is a Node CLI application, but it can be used to publish any type of packages.

 To publish a non-Node package (without a `package.json`) you would need to:
 - Use a [global](../usage/installation.md#global-installation) **semantic-release** installation
 - Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or rc file](../usage/configuration.md#configuration)
- Make sure your CI job executing the `semantic-release` command has access to [Node >= 10.18](#why-does-semantic-release-require-node-version--1018) to execute the `semantic-release` command
+- Make sure your CI job executing the `semantic-release` command has access to a version of Node that [meets our version requirement](./node-version.md) to execute the `semantic-release` command

-See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
+See the [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on specific CI environments.

-In addition you will need to configure the **semantic-release** [plugins](../usage/plugins.md#plugins) to disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin which is used by default and use a plugin for your project type.
+In addition, you will need to configure the **semantic-release** [plugins](../usage/plugins.md#plugins) to disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin which is used by default and use a plugin for your project type.

 If there is no specific plugin for your project type you can use the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to publish the release with a shell command.

@@ -101,7 +71,7 @@ Here is a basic example to create [GitHub releases](https://help.github.com/arti

 **Note**: This is a theoretical example where the command `set-version` update the project version with the value passed as its first argument and `publish-package` publishes the package to a registry.

-See the [package managers and languages recipes](../recipes/README.md#package-managers-and-languages) for more details on specific project types.
+See the [package managers and languages recipes](../recipes/release-workflow/README.md#package-managers-and-languages) for more details on specific project types.

 ## Can I use semantic-release with any CI service?

@@ -109,7 +79,7 @@ Yes, **semantic-release** can be used with any CI service, as long as it provide
 - A way to set [authentication](../usage/ci-configuration.md#authentication) via environment variables
 - A way to guarantee that the `semantic-release` command is [executed only after all the tests of all the jobs in the CI build pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded)

-See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
+See the [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on specific CI environments.

 ## Can I run semantic-release on my local machine rather than on a CI server?

@@ -125,7 +95,7 @@ However this is not the recommended approach, as running unit and integration te

 Yes, with the [`@semantic-release/gitlab-config`](https://github.com/semantic-release/gitlab-config) shareable configuration.

-See the [GitLab CI recipes](../recipes/gitlab-ci.md#using-semantic-release-with-gitlab-ci) for the CI configuration.
+See the [GitLab CI recipes](../recipes/ci-configurations/gitlab-ci.md#using-semantic-release-with-gitlab-ci) for the CI configuration.

 ## Can I use semantic-release with any Git hosted environment?

@@ -224,25 +194,15 @@ If you need more control over the timing of releases, see [Triggering a release]

 This is not supported by **semantic-release** as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero.

-If your project is under heavy development, with frequent breaking changes, and is not production ready yet we recommend [publishing pre-releases](../recipes/pre-releases.md#publishing-pre-releases).
+If your project is under heavy development, with frequent breaking changes, and is not production ready yet we recommend [publishing pre-releases](../recipes/release-workflow/pre-releases.md#publishing-pre-releases).

 See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) for more details on [Semantic Versioning](https://semver.org) and the recommendation to start at version `1.0.0`.

 ## Can I trust semantic-release with my releases?

-**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp).
+**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [verdaccio](https://www.npmjs.com/package/verdaccio).

-In addition the [verify conditions step](../../README.md#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
-
-## Why does semantic-release require Node version >= 10.18?
-
-**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 10.18 or higher**.
-
-See [Node version requirement](./node-version.md#node-version-requirement) for more details and solutions.
-
-## Why does semantic-release require Git version >= 2.7.1?
-
-**semantic-release** uses Git CLI commands to read information about the repository such as branches, commit history and tags. Certain commands and options (such as [the `--merged` option of the `git tag` command](https://git-scm.com/docs/git-tag/2.7.0#git-tag---no-mergedltcommitgt) or bug fixes related to `git ls-files`) used by **semantic-release** are only available in Git version 2.7.1 and higher.
+In addition, the [verify conditions step](../../README.md#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).

 ## What is npx?

@@ -0,0 +1,4 @@
+# Git version requirement
+
+**semantic-release** uses Git CLI commands to read information about the repository such as branches, commit history and tags.
+Certain commands and options (such as [the `--merged` option of the `git tag` command](https://git-scm.com/docs/git-tag/2.7.0#git-tag---no-mergedltcommitgt) or bug fixes related to `git ls-files`) used by **semantic-release** are only available in Git version 2.7.1 and higher.
@@ -1,13 +1,21 @@
 # Node Support Policy

-We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 8.9.0 (LTS)](https://nodejs.org/en/blog/release/v8.9.0).
+We will always support at least the latest [Long-Term Support](https://github.com/nodejs/Release) version of Node, but provide no promise of support for older versions.
+The supported range will always be defined in the `engines.node` property of the `package.json` of our packages.

 We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment.

-It's possible this package will work correctly on newer versions of Node. It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.
+It's possible this package will work correctly on newer versions of Node.
+It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.

-As each Node LTS version reaches its end-of-life we will remove that version from the node engines property of our package's package.json file. Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package. We will not accept any requests to support an end-of-life version of Node. Any merge requests or issues supporting an end-of-life version of Node will be closed.
+As new Node LTS versions become available we may remove previous versions from the `engines.node` property of our package's `package.json` file.
+Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package.
+We will not accept any requests to support an end-of-life version of Node.
+Any merge requests or issues supporting an end-of-life version of Node will be closed.

-We will accept code that allows this package to run on newer, non-LTS, versions of Node. Furthermore, we will attempt to ensure our own changes work on the latest version of Node. To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.
+We will accept code that allows this package to run on newer, non-LTS, versions of Node.
+Furthermore, we will attempt to ensure our own changes work on the latest version of Node.
+To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.

-JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property. If you encounter issues installing this package, please report the issue to your package manager.
+JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property.
+If you encounter issues installing this package, please report the issue to your package manager.
@@ -1,35 +1,38 @@
 # Node version requirement

-**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 10 or higher**.
+**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 14.17 or higher**.

-**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency. Therefore the only constraint is to run the `semantic-release` in a CI environment providing Node 8 or higher.
+**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency.
+Therefore, the only constraint is to run the `semantic-release` in a CI environment providing version of Node that meets our version requirement.

 See our [Node Support Policy](node-support-policy.md) for our long-term promise regarding Node version support.

 ## Recommended solution

-### Run at least one CI job with Node >= 10.18
+### Run at least one CI job with a version of Node that meets our version requirement

-The recommended approach is to run the `semantic-release` command from a CI job running on Node 10.18 or higher. This can either be a job used by your project to test on Node >= 10.18 or a dedicated job for the release steps.
+The recommended approach is to run the `semantic-release` command from a CI job running on the latest available LTS version of node.
+This can either be a job used by your project to test on the latest Node LTS version or a dedicated job for the release steps.

-See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.
+See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details.

 ## Alternative solutions

-### Use `npx`
+### Use `npx` to execute in the latest LTS version of Node

-`npx` is included with npm >= 5.2 and can be used to download the latest [Node 8 package published on npm](https://www.npmjs.com/package/node). Use it to execute the `semantic-release` command.
+`npx` is included with npm >= 5.2 and can be used to download the latest [Node LTS package published on npm](https://www.npmjs.com/package/node).
+Use it to execute the `semantic-release` command.

 ```bash
-$ npx -p node@8 -c "npx semantic-release"
+$ npx -p node@lts -c "npx semantic-release"
 ```

-**Note:**: See [What is npx](./FAQ.md#what-is-npx) for more details.
+**Note**: See [What is npx](./FAQ.md#what-is-npx) for more details.

 ### Use `nvm`

-If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 8 before running the `semantic-release` command.
+If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to the latest LTS version of Node before running the `semantic-release` command.

 ```bash
-$ nvm install 8 && npx semantic-release
+$ nvm install 'lts/*' && npx semantic-release
 ```
@@ -15,6 +15,7 @@
 - ["Introduction to SemVer" - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2)
 - ["Introduction to Semantic Release" - liv](https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8)
 - ["Series - Semantic Release Automation" - Abdelrahman Wahdan](https://dev.to/abdelrahmanahmed/semantic-release-and-how-to-automate-it-part-1-4pa2)
+- ["Explain semantic release and how to use it on GitLab pipeline"](https://regoo707.medium.com/auto-bump-apps-versions-and-releases-using-gitlab-pipeline-e32f1d7fa3ee)

 ## Tutorials

@@ -65,5 +65,5 @@ To recover from that situation, do the following:

 1. Delete the tag(s) for the release(s) that have been lost from the git history. You can delete each tag from remote using `git push origin :[TAG NAME]`, e.g. `git push origin :v2.0.0-beta.1`. You can delete tags locally using `git tag -d [TAG NAME]`, e.g. `git tag -d v2.0.0-beta.1`.
 2. Re-create the tags locally: `git tag [TAG NAME] [COMMIT HASH]`, where `[COMMIT HASH]` is the new commit that created the release for the lost tag. E.g. `git tag v2.0.0-beta.1 abcdef0`
-3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' v3.0.0-beta.1`. If the release was also published in the default channel (usually `master`), then set the first channel to `null`, e.g. `git notes --ref semantic-release add -f -m '{"channels":[null, "beta"]}'
+3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' v2.0.0-beta.1`. If the release was also published in the default channel (usually `master`), then set the first channel to `null`, e.g. `git notes --ref semantic-release add -f -m '{"channels":[null, "beta"]}'`
 4. Push the local notes: `git push --force origin refs/notes/semantic-release`. The `--force` is needed after the rebase. Be careful.
@@ -8,12 +8,12 @@ Here is a few example of the CI services that can be used to achieve this:
 - [CircleCI Workflows](https://circleci.com/docs/2.0/workflows)
 - [GitHub Actions](https://github.com/features/actions)
 - [Codeship Deployment Pipelines](https://documentation.codeship.com/basic/builds-and-configuration/deployment-pipelines)
- [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html#introduction-to-pipelines-and-jobs)
+- [GitLab Pipelines](https://docs.gitlab.com/ce/ci/introduction/)
 - [Codefresh Pipelines](https://codefresh.io/docs/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines)
 - [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
 - [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).

-See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.
+See [CI configuration recipes](../recipes/ci-configurations/README.md) for more details.

 ## Authentication

@@ -29,7 +29,7 @@ See [CI configuration recipes](../recipes/README.md#ci-configurations) for more
 | `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clearification `user:token` has to be the value of this env.        |
 | `GIT_CREDENTIALS`                                     | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `<username>:<password>`. The username and password must each be individually URL encoded, not the `:` separating them. |

-Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-auth-ssh-keys.md).
+Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-hosted-services/git-auth-ssh-keys.md).

 ### Authentication for plugins

@@ -44,6 +44,6 @@ See each plugin's documentation for the environment variables required.

 The authentication token/credentials have to be made available in the CI service via environment variables.

-See [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on how to configure environment variables in your CI service.
+See [CI configuration recipes](../recipes/ci-configurations/README.md) for more details on how to configure environment variables in your CI service.

 **Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab).
@@ -24,6 +24,9 @@ For other type of projects we recommend installing **semantic-release** directly
 $ npx semantic-release
 ```

-**Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@15`). This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released.
+**Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with `npx semantic-release@18`).
+This way your build will not automatically use the next major **semantic-release** release that could possibly break your build.
+You will have to upgrade manually when a new major version is released.

-**Note**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.
+**Note**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it.
+See [What is npx](../support/FAQ.md#what-is-npx) for more details.
@@ -16,6 +16,8 @@ A plugin is a npm module that can implement one or more of the following steps:
 | `success`          | No       | Responsible for notifying of a new release.                                                                                                                                                                          |
 | `fail`             | No       | Responsible for notifying of a failed release.                                                                                                                                                                       |

+Release steps will run in that order. At each step, **semantic-release** will run every plugin in the [`plugins` array](#plugins-declaration-and-execution-order), as long as the plugin implements the step.
+
 **Note:** If no plugin with a `analyzeCommits` step is defined `@semantic-release/commit-analyzer` will be used.

 ## Plugins installation
@@ -70,6 +72,8 @@ With this configuration **semantic-release** will:
 - execute the `prepare` implementation of `@semantic-release/npm` then `@semantic-release/git`
 - execute the `publish` implementation of `@semantic-release/npm`

+Order is first determined by release steps (such as `verifyConditions` → `anayzeCommits`). At each release step, plugins are executed in the order in which they are defined.
+
 ## Plugin options configuration

 A plugin configuration can be specified by wrapping the name and an options object in an array. Options configured this way will be passed only to that specific plugin.
@@ -1,19 +1,19 @@
 # Workflow configuration

 **semantic-release** allow to manage and automate complex release workflow, based on multiple Git branches and distribution channels. This allow to:
- Distributes certain releases to a particular group of users via distribution channels
+- Distribute certain releases to a particular group of users via distribution channels
 - Manage the availability of releases on distribution channels via branches merge
 - Maintain multiple lines of releases in parallel
 - Work on large future releases outside the normal flow of one version increment per Git push

-See [Release workflow recipes](../recipes/README.md#release-workflow) for detailed examples.
+See [Release workflow recipes](../recipes/release-workflow/README.md#release-workflow) for detailed examples.

 The release workflow is configured via the [branches option](./configuration.md#branches) which accepts a single or an array of branch definitions.
 Each branch can be defined either as a string, a [glob](https://github.com/micromatch/micromatch#matching-features) or an object. For string and glob definitions each [property](#branches-properties) will be defaulted.

 A branch can defined as one of three types:
 - [release](#release-branches): to make releases on top of the last version released
- [maintenance](#maintenance-branches): to make release on top of an old release
+- [maintenance](#maintenance-branches): to make releases on top of an old release
 - [pre-release](#pre-release-branches): to make pre-releases

 The type of the branch is automatically determined based on naming convention and/or [properties](#branches-properties).
@@ -25,7 +25,7 @@ The type of the branch is automatically determined based on naming convention an
 | `name`       | All                                       | **Required.** The Git branch holding the commits to analyze and the code to release. See [name](#name).                                                                                 | - The value itself if defined as a `String` or the matching branches name if defined as a glob. |
 | `channel`    | All                                       | The distribution channel on which to publish releases from this branch. Set to `false` to force the default distribution channel instead of using the default. See [channel](#channel). | `undefined` for the first release branch, the value of `name` for subsequent ones.              |
 | `range`      | [maintenance](#maintenance-branches) only | **Required unless `name` is formatted like `N.N.x` or `N.x` (`N` is a number).** The range of [semantic versions](https://semver.org) to support on this branch. See [range](#range).   | The value of `name`.                                                                            |
-| `prerelease` | [pre-release](#pre-release-branches) only | **Required.** The pre-release detonation to append to [semantic versions](https://semver.org) released from this branch. See [prerelease](#prerelease).                                 | -                                                                                               |
+| `prerelease` | [pre-release](#pre-release-branches) only | **Required.** The pre-release denotation to append to [semantic versions](https://semver.org) released from this branch. See [prerelease](#prerelease).                                 | -                                                                                               |

 ### name

@@ -91,7 +91,7 @@ For example the configuration `['master', {name: 'pre/rc', prerelease: '${name.r
  branches: [
    {name: 'master'},
    {name: 'pre/rc', channel: 'pre/rc', prerelease: 'rc'}, // `prerelease` is built with the template `${name.replace(/^pre\\//g, "")}`
-    {name: 'beta', channel: 'beta', prerelease: 'beta'}, // `prerelease` is set to `beta` as it is the value of `name`
+    {name: 'beta', channel: 'beta', prerelease: true}, // `prerelease` is set to `beta` as it is the value of `name`
  ]
 }
 ```
@@ -108,7 +108,7 @@ A project must define a minimum of 1 release branch and can have a maximum of 3.

 **Note:** With **semantic-release** as with most package managers, a release version must be unique, independently of the distribution channel on which it is available.

-See [publishing on distribution channels recipe](../recipes/distribution-channels.md) for a detailed example.
+See [publishing on distribution channels recipe](../recipes/release-workflow/distribution-channels.md) for a detailed example.

 #### Pushing to a release branch

@@ -142,7 +142,7 @@ Maintenance branches are always considered lower than [release branches](#releas

 **semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release or maintenance branch to another maintenance branch](#merging-into-a-maintenance-branch), however only versions within the branch `range` can be merged. If a merged version is outside the maintenance branch `range`, **semantic-release** will not add to the corresponding channel and will throw an `EINVALIDMAINTENANCEMERGE` error.

-See [publishing maintenance releases recipe](../recipes/maintenance-releases.md) for a detailed example.
+See [publishing maintenance releases recipe](../recipes/release-workflow/maintenance-releases.md) for a detailed example.

 #### Pushing to a maintenance branch

@@ -162,7 +162,7 @@ With the configuration `"branches": ["1.0.x", "1.x", "master"]`, if the last rel
 ### Pre-release branches

 A pre-release branch is a type of branch used by **semantic-release** that allows to publish releases with a [pre-release version](https://semver.org/#spec-item-9).
-Using a pre-release version allow to publish multiple releases with the same version. Those release will be differentiated via there identifiers (in `1.0.0-alpha.1` the identifier is `alpha.1`).
+Using a pre-release version allow to publish multiple releases with the same version. Those release will be differentiated via their identifiers (in `1.0.0-alpha.1` the identifier is `alpha.1`).
 This is useful when you need to work on a future major release that will include many breaking changes but you do not want to increment the version number for each breaking change commit.

 A pre-release branch is characterized by the `prerelease` property that defines the static part of the version released (in `1.0.0-alpha.1` the static part fo the identifier is `alpha`). The [`prerelease`](#prerelease) value of each pre-release branch must be unique across the project.
@@ -171,7 +171,7 @@ A pre-release branch is characterized by the `prerelease` property that defines

 When merging commits associated with an existing release, **semantic-release** will treat them as [pushed commits](#pushing-to-a-pre-release-branch) and publish a new release if necessary, but it will never add those releases to the distribution channel corresponding to the pre-release branch.

-See [publishing pre-releases recipe](../recipes/pre-releases.md) for a detailed example.
+See [publishing pre-releases recipe](../recipes/release-workflow/pre-releases.md) for a detailed example.

 #### Pushing to a pre-release branch

@@ -1,6 +1,5 @@
 const {pick} = require('lodash');
 const marked = require('marked');
-const TerminalRenderer = require('marked-terminal');
 const envCi = require('env-ci');
 const hookStd = require('hook-std');
 const semver = require('semver');
@@ -21,7 +20,16 @@ const {verifyAuth, isBranchUpToDate, getGitHead, tag, push, pushNotes, getTagHea
 const getError = require('./lib/get-error');
 const {COMMIT_NAME, COMMIT_EMAIL} = require('./lib/definitions/constants');

-marked.setOptions({renderer: new TerminalRenderer()});
+let markedOptionsSet = false;
+async function terminalOutput(text) {
+  if (!markedOptionsSet) {
+    const {default: TerminalRenderer} = await import('marked-terminal'); // eslint-disable-line node/no-unsupported-features/es-syntax
+    marked.setOptions({renderer: new TerminalRenderer()});
+    markedOptionsSet = true;
+  }
+
+  return marked.parse(text);
+}

 /* eslint complexity: off */
 async function run(context, plugins) {
@@ -207,20 +215,20 @@ async function run(context, plugins) {
  if (options.dryRun) {
    logger.log(`Release note for version ${nextRelease.version}:`);
    if (nextRelease.notes) {
-      context.stdout.write(marked(nextRelease.notes));
+      context.stdout.write(await terminalOutput(nextRelease.notes));
    }
  }

  return pick(context, ['lastRelease', 'commits', 'nextRelease', 'releases']);
 }

-function logErrors({logger, stderr}, err) {
+async function logErrors({logger, stderr}, err) {
  const errors = extractErrors(err).sort((error) => (error.semanticRelease ? -1 : 0));
  for (const error of errors) {
    if (error.semanticRelease) {
      logger.error(`${error.code} ${error.message}`);
      if (error.details) {
-        stderr.write(marked(error.details));
+        stderr.write(await terminalOutput(error.details)); // eslint-disable-line no-await-in-loop
      }
    } else {
      logger.error('An error occurred while running semantic-release: %O', error);
@@ -234,7 +242,7 @@ async function callFail(context, plugins, err) {
    try {
      await plugins.fail({...context, errors});
    } catch (error) {
-      logErrors(context, error);
+      await logErrors(context, error);
    }
  }
 }
@@ -265,7 +273,7 @@ module.exports = async (cliOptions = {}, {cwd = process.cwd(), env = process.env
      throw error;
    }
  } catch (error) {
-    logErrors(context, error);
+    await logErrors(context, error);
    unhook();
    throw error;
  }
@@ -60,7 +60,7 @@ Your configuration for the \`tagFormat\` option is \`${stringify(tagFormat)}\`.`
    message: `The \`${type}\` plugin configuration is invalid.`,
    details: `The [${type} plugin configuration](${linkify(`docs/usage/plugins.md#${toLower(type)}-plugin`)}) ${
      required ? 'is required and ' : ''
-    } must be a single or an array of plugins definition. A plugin definition is an npm module name, optionnaly wrapped in an array with an object.
+    } must be a single or an array of plugins definition. A plugin definition is an npm module name, optionally wrapped in an array with an object.

 Your configuration for the \`${type}\` plugin is \`${stringify(pluginConf)}\`.`,
  }),
@@ -68,7 +68,7 @@ Your configuration for the \`${type}\` plugin is \`${stringify(pluginConf)}\`.`,
    message: 'The `plugins` configuration is invalid.',
    details: `The [plugins](${linkify(
      'docs/usage/configuration.md#plugins'
-    )}) option must be an array of plugin definions. A plugin definition is an npm module name, optionnaly wrapped in an array with an object.
+    )}) option must be an array of plugin definions. A plugin definition is an npm module name, optionally wrapped in an array with an object.

 The invalid configuration is \`${stringify(plugin)}\`.`,
  }),
@@ -9,19 +9,10 @@ const plugins = require('./plugins');
 const {validatePlugin, parseConfig} = require('./plugins/utils');

 const CONFIG_NAME = 'release';
-const CONFIG_FILES = [
-  'package.json',
-  `.${CONFIG_NAME}rc`,
-  `.${CONFIG_NAME}rc.json`,
-  `.${CONFIG_NAME}rc.yaml`,
-  `.${CONFIG_NAME}rc.yml`,
-  `.${CONFIG_NAME}rc.js`,
-  `${CONFIG_NAME}.config.js`,
-];

 module.exports = async (context, cliOptions) => {
  const {cwd, env} = context;
-  const {config, filepath} = (await cosmiconfig(CONFIG_NAME, {searchPlaces: CONFIG_FILES}).search(cwd)) || {};
+  const {config, filepath} = (await cosmiconfig(CONFIG_NAME).search(cwd)) || {};

  debug('load config from: %s', filepath);

@@ -318,7 +318,7 @@ async function getNote(ref, execaOptions) {
 }

 /**
- * Get and parse the JSON note of a given reference.
+ * Add JSON note to a given reference.
 *
 * @param {Object} note The object to save in the reference note.
 * @param {String} ref The Git reference to add the note to.
@@ -20,25 +20,25 @@
    "Pierre Vanduynslager (https://twitter.com/@pvdlg_)"
  ],
  "dependencies": {
-    "@semantic-release/commit-analyzer": "^8.0.0",
-    "@semantic-release/error": "^2.2.0",
-    "@semantic-release/github": "^7.0.0",
-    "@semantic-release/npm": "^7.0.0",
-    "@semantic-release/release-notes-generator": "^9.0.0",
+    "@semantic-release/commit-analyzer": "^9.0.2",
+    "@semantic-release/error": "^3.0.0",
+    "@semantic-release/github": "^8.0.0",
+    "@semantic-release/npm": "^9.0.0",
+    "@semantic-release/release-notes-generator": "^10.0.0",
    "aggregate-error": "^3.0.0",
-    "cosmiconfig": "^6.0.0",
+    "cosmiconfig": "^7.0.0",
    "debug": "^4.0.0",
    "env-ci": "^5.0.0",
-    "execa": "^4.0.0",
+    "execa": "^5.0.0",
    "figures": "^3.0.0",
    "find-versions": "^4.0.0",
-    "get-stream": "^5.0.0",
+    "get-stream": "^6.0.0",
    "git-log-parser": "^1.2.0",
    "hook-std": "^2.0.0",
-    "hosted-git-info": "^3.0.0",
-    "lodash": "^4.17.15",
-    "marked": "^1.0.0",
-    "marked-terminal": "^4.0.0",
+    "hosted-git-info": "^4.0.0",
+    "lodash": "^4.17.21",
+    "marked": "^4.0.10",
+    "marked-terminal": "^5.0.0",
    "micromatch": "^4.0.2",
    "p-each-series": "^2.1.0",
    "p-reduce": "^2.0.0",
@@ -50,27 +50,27 @@
    "yargs": "^16.2.0"
  },
  "devDependencies": {
-    "ava": "^3.1.0",
-    "clear-module": "^4.0.0",
-    "codecov": "^3.0.0",
-    "delay": "^4.0.0",
-    "dockerode": "^3.0.0",
-    "file-url": "^3.0.0",
-    "fs-extra": "^9.0.0",
-    "got": "^11.0.0",
-    "js-yaml": "^3.10.0",
-    "mockserver-client": "^5.1.1",
-    "nock": "^12.0.0",
-    "nyc": "^15.0.0",
-    "p-retry": "^4.0.0",
-    "proxyquire": "^2.0.0",
-    "sinon": "^9.0.0",
-    "stream-buffers": "^3.0.2",
-    "tempy": "^0.5.0",
-    "xo": "^0.29.0"
+    "ava": "3.15.0",
+    "clear-module": "4.1.2",
+    "codecov": "3.8.3",
+    "delay": "5.0.0",
+    "dockerode": "3.3.1",
+    "file-url": "3.0.0",
+    "fs-extra": "9.1.0",
+    "got": "11.8.3",
+    "js-yaml": "4.1.0",
+    "mockserver-client": "5.11.2",
+    "nock": "13.2.1",
+    "nyc": "15.1.0",
+    "p-retry": "4.6.1",
+    "proxyquire": "2.1.3",
+    "sinon": "12.0.1",
+    "stream-buffers": "3.0.2",
+    "tempy": "1.0.1",
+    "xo": "0.29.1"
  },
  "engines": {
-    "node": ">=10.18"
+    "node": ">=16 || ^14.17"
  },
  "files": [
    "bin",
@@ -122,7 +122,8 @@
    "lint": "xo",
    "pretest": "npm run lint",
    "semantic-release": "./bin/semantic-release.js",
-    "test": "nyc ava -v"
+    "test": "nyc ava -v",
+    "test:ci": "nyc ava -v"
  },
  "xo": {
    "prettier": true,
@@ -130,5 +131,10 @@
    "rules": {
      "unicorn/string-content": "off"
    }
+  },
+  "renovate": {
+    "extends": [
+      "github>semantic-release/.github"
+    ]
  }
 }
@@ -136,7 +136,7 @@ test('Read options from .releaserc.yml', async (t) => {
    plugins: false,
  };
  // Create package.json in repository root
-  await writeFile(path.resolve(cwd, '.releaserc.yml'), yaml.safeDump(options));
+  await writeFile(path.resolve(cwd, '.releaserc.yml'), yaml.dump(options));

  const {options: result} = await t.context.getConfig({cwd});

@@ -191,6 +191,28 @@ test('Read options from .releaserc.js', async (t) => {
  t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
 });

+test('Read options from .releaserc.cjs', async (t) => {
+  // Create a git repository, set the current working directory at the root of the repo
+  const {cwd} = await gitRepo();
+  const options = {
+    analyzeCommits: {path: 'analyzeCommits', param: 'analyzeCommits_param'},
+    branches: ['test_branch'],
+    repositoryUrl: 'https://host.null/owner/module.git',
+    tagFormat: `v\${version}`,
+    plugins: false,
+  };
+  // Create .releaserc.cjs in repository root
+  await writeFile(path.resolve(cwd, '.releaserc.cjs'), `module.exports = ${JSON.stringify(options)}`);
+
+  const {options: result} = await t.context.getConfig({cwd});
+
+  const expected = {...options, branches: ['test_branch']};
+  // Verify the options contains the plugin config from .releaserc.cjs
+  t.deepEqual(result, expected);
+  // Verify the plugins module is called with the plugin options from .releaserc.cjs
+  t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
+});
+
 test('Read options from release.config.js', async (t) => {
  // Create a git repository, set the current working directory at the root of the repo
  const {cwd} = await gitRepo();
@@ -213,6 +235,28 @@ test('Read options from release.config.js', async (t) => {
  t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
 });

+test('Read options from release.config.cjs', async (t) => {
+  // Create a git repository, set the current working directory at the root of the repo
+  const {cwd} = await gitRepo();
+  const options = {
+    analyzeCommits: {path: 'analyzeCommits', param: 'analyzeCommits_param'},
+    branches: ['test_branch'],
+    repositoryUrl: 'https://host.null/owner/module.git',
+    tagFormat: `v\${version}`,
+    plugins: false,
+  };
+  // Create release.config.cjs in repository root
+  await writeFile(path.resolve(cwd, 'release.config.cjs'), `module.exports = ${JSON.stringify(options)}`);
+
+  const {options: result} = await t.context.getConfig({cwd});
+
+  const expected = {...options, branches: ['test_branch']};
+  // Verify the options contains the plugin config from release.config.cjs
+  t.deepEqual(result, expected);
+  // Verify the plugins module is called with the plugin options from release.config.cjs
+  t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
+});
+
 test('Prioritise CLI/API parameters over file configuration and git repo', async (t) => {
  // Create a git repository, set the current working directory at the root of the repo
  let {cwd, repositoryUrl} = await gitRepo();
@@ -0,0 +1,23 @@
+storage: /verdaccio/storage/data
+plugins: /verdaccio/plugins
+web:
+  title: Verdaccio
+auth:
+  htpasswd:
+    file: /verdaccio/storage/htpasswd
+packages:
+  '@*/*':
+    access: $all
+    publish: $authenticated
+    unpublish: $authenticated
+  '**':
+    access: $all
+    publish: $authenticated
+    unpublish: $authenticated
+server:
+  keepAliveTimeout: 60
+middlewares:
+  audit:
+    enabled: true
+logs:
+  - { type: stdout, format: pretty, level: http }
@@ -25,8 +25,12 @@ const {GIT_NOTE_REF} = require('../../lib/definitions/constants');
 */
 async function initGit(withRemote) {
  const cwd = tempy.directory();
+  const args = withRemote ? ['--bare', '--initial-branch=master'] : ['--initial-branch=master'];

-  await execa('git', ['init', ...(withRemote ? ['--bare'] : [])], {cwd});
+  await execa('git', ['init', ...args], {cwd}).catch(() => {
+    const args = withRemote ? ['--bare'] : [];
+    return execa('git', ['init', ...args], {cwd});
+  });
  const repositoryUrl = fileUrl(cwd);
  return {cwd, repositoryUrl};
 }
@@ -63,7 +63,7 @@ async function createRepo(name, branch = 'master', description = `Repository ${n
  const authUrl = `http://${gitCredential}@${SERVER_HOST}:${HOST_PORT}/git/${name}.git`;

  // Retry as the server might take a few ms to make the repo available push
-  await pRetry(() => initBareRepo(authUrl, branch), {retries: 3, minTimeout: 500, factor: 2});
+  await pRetry(() => initBareRepo(authUrl, branch), {retries: 5, minTimeout: 500, factor: 2});
  const cwd = await gitShallowClone(authUrl);

  return {cwd, repositoryUrl, authUrl};
@@ -1,15 +1,13 @@
 const Docker = require('dockerode');
 const getStream = require('get-stream');
 const got = require('got');
+const path = require('path');
 const delay = require('delay');
 const pRetry = require('p-retry');

-const IMAGE = 'semanticrelease/npm-registry-docker:latest';
-const SERVER_PORT = 15986;
-const COUCHDB_PORT = 5984;
-const SERVER_HOST = 'localhost';
-const COUCHDB_USER = 'admin';
-const COUCHDB_PASSWORD = 'password';
+const IMAGE = 'verdaccio/verdaccio:4';
+const REGISTRY_PORT = 4873;
+const REGISTRY_HOST = 'localhost';
 const NPM_USERNAME = 'integration';
 const NPM_PASSWORD = 'suchsecure';
 const NPM_EMAIL = 'integration@test.com';
@@ -25,8 +23,8 @@ async function start() {
  container = await docker.createContainer({
    Tty: true,
    Image: IMAGE,
-    PortBindings: {[`${COUCHDB_PORT}/tcp`]: [{HostPort: `${SERVER_PORT}`}]},
-    Env: [`COUCHDB_USER=${COUCHDB_USER}`, `COUCHDB_PASSWORD=${COUCHDB_PASSWORD}`],
+    PortBindings: {[`${REGISTRY_PORT}/tcp`]: [{HostPort: `${REGISTRY_PORT}`}]},
+    Binds: [`${path.join(__dirname, 'config.yaml')}:/verdaccio/conf/config.yaml`],
  });

  await container.start();
@@ -34,7 +32,7 @@ async function start() {

  try {
    // Wait for the registry to be ready
-    await pRetry(() => got(`http://${SERVER_HOST}:${SERVER_PORT}/registry/_design/app`, {cache: false}), {
+    await pRetry(() => got(`http://${REGISTRY_HOST}:${REGISTRY_PORT}/`, {cache: false}), {
      retries: 7,
      minTimeout: 1000,
      factor: 2,
@@ -44,9 +42,7 @@ async function start() {
  }

  // Create user
-  await got(`http://${SERVER_HOST}:${SERVER_PORT}/_users/org.couchdb.user:${NPM_USERNAME}`, {
-    username: COUCHDB_USER,
-    password: COUCHDB_PASSWORD,
+  await got(`http://${REGISTRY_HOST}:${REGISTRY_PORT}/-/user/org.couchdb.user:${NPM_USERNAME}`, {
    method: 'PUT',
    json: {
      _id: `org.couchdb.user:${NPM_USERNAME}`,
@@ -59,7 +55,7 @@ async function start() {
  });
 }

-const url = `http://${SERVER_HOST}:${SERVER_PORT}/registry/_design/app/_rewrite/`;
+const url = `http://${REGISTRY_HOST}:${REGISTRY_PORT}/`;

 const authEnv = {
  npm_config_registry: url, // eslint-disable-line camelcase
@@ -29,17 +29,20 @@ const npmRegistry = require('./helpers/npm-registry');
 const requireNoCache = proxyquire.noPreserveCache();

 // Environment variables used with semantic-release cli (similar to what a user would setup)
+const {GITHUB_ACTION, GITHUB_TOKEN, ...processEnvWithoutGitHubActionsVariables} = process.env;
 const env = {
+  ...processEnvWithoutGitHubActionsVariables,
  ...npmRegistry.authEnv,
-  GH_TOKEN: gitbox.gitCredential,
-  GITHUB_URL: mockServer.url,
-  TRAVIS: 'true',
  CI: 'true',
+  GH_TOKEN: gitbox.gitCredential,
+  TRAVIS: 'true',
  TRAVIS_BRANCH: 'master',
  TRAVIS_PULL_REQUEST: 'false',
+  GITHUB_API_URL: mockServer.url,
 };
+
 // Environment variables used only for the local npm command used to do verification
-const testEnv = {
+const npmTestEnv = {
  ...process.env,
  ...npmRegistry.authEnv,
  npm_config_registry: npmRegistry.url,
@@ -74,7 +77,7 @@ test('Release patch, minor and major versions', async (t) => {
    release: {branches: ['master', 'next'], success: false, fail: false},
  });
  // Create a npm-shrinkwrap.json file
-  await execa('npm', ['shrinkwrap'], {env: testEnv, cwd});
+  await execa('npm', ['shrinkwrap'], {env: npmTestEnv, cwd, extendEnv: false});

  /* No release */
  let verifyMock = await mockServer.mock(
@@ -85,7 +88,7 @@ test('Release patch, minor and major versions', async (t) => {
  t.log('Commit a chore');
  await gitCommits(['chore: Init repository'], {cwd});
  t.log('$ semantic-release');
-  let {stdout, exitCode} = await execa(cli, [], {env, cwd});
+  let {stdout, exitCode} = await execa(cli, [], {env, cwd, extendEnv: false});
  t.regex(stdout, /There are no relevant changes, so no new version is released/);
  t.is(exitCode, 0);

@@ -108,7 +111,7 @@ test('Release patch, minor and major versions', async (t) => {
  t.log('Commit a feature');
  await gitCommits(['feat: Initial commit'], {cwd});
  t.log('$ semantic-release');
-  ({stdout, exitCode} = await execa(cli, [], {env, cwd}));
+  ({stdout, exitCode} = await execa(cli, [], {env, cwd, extendEnv: false}));
  t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
  t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
  t.is(exitCode, 0);
@@ -120,7 +123,7 @@ test('Release patch, minor and major versions', async (t) => {
  // Retrieve the published package from the registry and check version and gitHead
  let {
    'dist-tags': {latest: releasedVersion},
-  } = await npmView(packageName, testEnv);
+  } = await npmView(packageName, npmTestEnv);
  let head = await gitHead({cwd});
  t.is(releasedVersion, version);
  t.is(await gitTagHead(`v${version}`, {cwd}), head);
@@ -149,7 +152,7 @@ test('Release patch, minor and major versions', async (t) => {
  t.log('Commit a fix');
  await gitCommits(['fix: bar'], {cwd});
  t.log('$ semantic-release');
-  ({stdout, exitCode} = await execa(cli, [], {env, cwd}));
+  ({stdout, exitCode} = await execa(cli, [], {env, cwd, extendEnv: false}));
  t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
  t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
  t.is(exitCode, 0);
@@ -161,7 +164,7 @@ test('Release patch, minor and major versions', async (t) => {
  // Retrieve the published package from the registry and check version and gitHead
  ({
    'dist-tags': {latest: releasedVersion},
-  } = await npmView(packageName, testEnv));
+  } = await npmView(packageName, npmTestEnv));
  head = await gitHead({cwd});
  t.is(releasedVersion, version);
  t.is(await gitTagHead(`v${version}`, {cwd}), head);
@@ -190,7 +193,7 @@ test('Release patch, minor and major versions', async (t) => {
  t.log('Commit a feature');
  await gitCommits(['feat: baz'], {cwd});
  t.log('$ semantic-release');
-  ({stdout, exitCode} = await execa(cli, [], {env, cwd}));
+  ({stdout, exitCode} = await execa(cli, [], {env, cwd, extendEnv: false}));
  t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
  t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
  t.is(exitCode, 0);
@@ -202,7 +205,7 @@ test('Release patch, minor and major versions', async (t) => {
  // Retrieve the published package from the registry and check version and gitHead
  ({
    'dist-tags': {latest: releasedVersion},
-  } = await npmView(packageName, testEnv));
+  } = await npmView(packageName, npmTestEnv));
  head = await gitHead({cwd});
  t.is(releasedVersion, version);
  t.is(await gitTagHead(`v${version}`, {cwd}), head);
@@ -233,7 +236,7 @@ test('Release patch, minor and major versions', async (t) => {
  await gitPush('origin', 'next', {cwd});
  await gitCommits(['feat: foo\n\n BREAKING CHANGE: bar'], {cwd});
  t.log('$ semantic-release');
-  ({stdout, exitCode} = await execa(cli, [], {env: {...env, TRAVIS_BRANCH: 'next'}, cwd}));
+  ({stdout, exitCode} = await execa(cli, [], {env: {...env, TRAVIS_BRANCH: 'next'}, cwd, extendEnv: false}));
  t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
  t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
  t.is(exitCode, 0);
@@ -245,7 +248,7 @@ test('Release patch, minor and major versions', async (t) => {
  // Retrieve the published package from the registry and check version and gitHead
  ({
    'dist-tags': {next: releasedVersion},
-  } = await npmView(packageName, testEnv));
+  } = await npmView(packageName, npmTestEnv));
  head = await gitHead({cwd});
  t.is(releasedVersion, version);
  t.is(await gitGetNote(`v${version}`, {cwd}), '{"channels":["next"]}');
@@ -283,7 +286,7 @@ test('Release patch, minor and major versions', async (t) => {
  await merge('next', {cwd});
  await gitPush('origin', 'master', {cwd});
  t.log('$ semantic-release');
-  ({stdout, exitCode} = await execa(cli, [], {env, cwd}));
+  ({stdout, exitCode} = await execa(cli, [], {env, cwd, extendEnv: false}));
  t.regex(stdout, new RegExp(`Updated GitHub release: release-url/${version}`));
  t.regex(stdout, new RegExp(`Adding version ${version} to npm registry on dist-tag latest`));
  t.is(exitCode, 0);
@@ -293,7 +296,7 @@ test('Release patch, minor and major versions', async (t) => {
  // Retrieve the published package from the registry and check version and gitHead
  ({
    'dist-tags': {latest: releasedVersion},
-  } = await npmView(packageName, testEnv));
+  } = await npmView(packageName, npmTestEnv));
  t.is(releasedVersion, version);
  t.is(await gitGetNote(`v${version}`, {cwd}), '{"channels":["next",null]}');
  t.is(await gitTagHead(`v${version}`, {cwd}), await gitTagHead(`v${version}`, {cwd}));
@@ -318,7 +321,7 @@ test('Exit with 1 if a plugin is not found', async (t) => {
    release: {analyzeCommits: 'non-existing-path', success: false, fail: false},
  });

-  const {exitCode, stderr} = await t.throwsAsync(execa(cli, [], {env, cwd}));
+  const {exitCode, stderr} = await t.throwsAsync(execa(cli, [], {env, cwd, extendEnv: false}));
  t.is(exitCode, 1);
  t.regex(stderr, /Cannot find module/);
 });
@@ -336,7 +339,7 @@ test('Exit with 1 if a shareable config is not found', async (t) => {
    release: {extends: 'non-existing-path', success: false, fail: false},
  });

-  const {exitCode, stderr} = await t.throwsAsync(execa(cli, [], {env, cwd}));
+  const {exitCode, stderr} = await t.throwsAsync(execa(cli, [], {env, cwd, extendEnv: false}));
  t.is(exitCode, 1);
  t.regex(stderr, /Cannot find module/);
 });
@@ -357,7 +360,7 @@ test('Exit with 1 if a shareable config reference a not found plugin', async (t)
  });
  await writeJson(path.resolve(cwd, 'shareable.json'), shareable);

-  const {exitCode, stderr} = await t.throwsAsync(execa(cli, [], {env, cwd}));
+  const {exitCode, stderr} = await t.throwsAsync(execa(cli, [], {env, cwd, extendEnv: false}));
  t.is(exitCode, 1);
  t.regex(stderr, /Cannot find module/);
 });
@@ -387,7 +390,7 @@ test('Dry-run', async (t) => {
  t.log('Commit a feature');
  await gitCommits(['feat: Initial commit'], {cwd});
  t.log('$ semantic-release -d');
-  const {stdout, exitCode} = await execa(cli, ['-d'], {env, cwd});
+  const {stdout, exitCode} = await execa(cli, ['-d'], {env, cwd, extendEnv: false});
  t.regex(stdout, new RegExp(`There is no previous release, the next release version is ${version}`));
  t.regex(stdout, new RegExp(`Release note for version ${version}`));
  t.regex(stdout, /Initial commit/);
@@ -400,7 +403,6 @@ test('Dry-run', async (t) => {

 test('Allow local releases with "noCi" option', async (t) => {
  const envNoCi = {...env};
-  delete envNoCi.TRAVIS;
  delete envNoCi.CI;
  const packageName = 'test-no-ci';
  const owner = 'git';
@@ -435,7 +437,7 @@ test('Allow local releases with "noCi" option', async (t) => {
  t.log('Commit a feature');
  await gitCommits(['feat: Initial commit'], {cwd});
  t.log('$ semantic-release --no-ci');
-  const {stdout, exitCode} = await execa(cli, ['--no-ci'], {env: envNoCi, cwd});
+  const {stdout, exitCode} = await execa(cli, ['--no-ci'], {env: envNoCi, cwd, extendEnv: false});
  t.regex(stdout, new RegExp(`Published GitHub release: release-url/${version}`));
  t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
  t.is(exitCode, 0);
@@ -444,7 +446,7 @@ test('Allow local releases with "noCi" option', async (t) => {
  t.is((await readJson(path.resolve(cwd, 'package.json'))).version, version);

  // Retrieve the published package from the registry and check version and gitHead
-  const {version: releasedVersion, gitHead: releasedGitHead} = await npmView(packageName, testEnv);
+  const {version: releasedVersion, gitHead: releasedGitHead} = await npmView(packageName, npmTestEnv);

  const head = await gitHead({cwd});
  t.is(releasedVersion, version);
@@ -488,7 +490,7 @@ test('Pass options via CLI arguments', async (t) => {
      false,
      '--debug',
    ],
-    {env, cwd}
+    {env, cwd, extendEnv: false}
  );
  t.regex(stdout, new RegExp(`Publishing version ${version} to npm registry`));
  t.is(exitCode, 0);
@@ -497,7 +499,7 @@ test('Pass options via CLI arguments', async (t) => {
  t.is((await readJson(path.resolve(cwd, 'package.json'))).version, version);

  // Retrieve the published package from the registry and check version and gitHead
-  const {version: releasedVersion, gitHead: releasedGitHead} = await npmView(packageName, testEnv);
+  const {version: releasedVersion, gitHead: releasedGitHead} = await npmView(packageName, npmTestEnv);
  const head = await gitHead({cwd});
  t.is(releasedVersion, version);
  t.is(releasedGitHead, head);
@@ -553,7 +555,7 @@ test('Run via JS API', async (t) => {
  t.is((await readJson(path.resolve(cwd, 'package.json'))).version, version);

  // Retrieve the published package from the registry and check version and gitHead
-  const {version: releasedVersion, gitHead: releasedGitHead} = await npmView(packageName, testEnv);
+  const {version: releasedVersion, gitHead: releasedGitHead} = await npmView(packageName, npmTestEnv);
  const head = await gitHead({cwd});
  t.is(releasedVersion, version);
  t.is(releasedGitHead, head);
@@ -582,7 +584,7 @@ test('Log unexpected errors from plugins and exit with 1', async (t) => {
  t.log('Commit a feature');
  await gitCommits(['feat: Initial commit'], {cwd});
  t.log('$ semantic-release');
-  const {stderr, exitCode} = await execa(cli, [], {env, cwd, reject: false});
+  const {stderr, exitCode} = await execa(cli, [], {env, cwd, reject: false, extendEnv: false});
  // Verify the type and message are logged
  t.regex(stderr, /Error: a/);
  // Verify the the stacktrace is logged
@@ -609,7 +611,7 @@ test('Log errors inheriting SemanticReleaseError and exit with 1', async (t) =>
  t.log('Commit a feature');
  await gitCommits(['feat: Initial commit'], {cwd});
  t.log('$ semantic-release');
-  const {stderr, exitCode} = await execa(cli, [], {env, cwd, reject: false});
+  const {stderr, exitCode} = await execa(cli, [], {env, cwd, reject: false, extendEnv: false});
  // Verify the type and message are logged
  t.regex(stderr, /EINHERITED Inherited error/);
  t.is(exitCode, 1);
@@ -630,7 +632,7 @@ test('Exit with 1 if missing permission to push to the remote repository', async
  const {stderr, exitCode} = await execa(
    cli,
    ['--repository-url', 'http://user:wrong_pass@localhost:2080/git/unauthorized.git'],
-    {env: {...env, GH_TOKEN: 'user:wrong_pass'}, cwd, reject: false}
+    {env: {...env, GH_TOKEN: 'user:wrong_pass'}, cwd, reject: false, extendEnv: false}
  );
  // Verify the type and message are logged
  t.regex(stderr, /EGITNOPERMISSION/);
@@ -650,7 +652,12 @@ test('Hide sensitive environment variable values from the logs', async (t) => {
  });

  t.log('$ semantic-release');
-  const {stdout, stderr} = await execa(cli, [], {env: {...env, MY_TOKEN: 'secret token'}, cwd, reject: false});
+  const {stdout, stderr} = await execa(cli, [], {
+    env: {...env, MY_TOKEN: 'secret token'},
+    cwd,
+    reject: false,
+    extendEnv: false,
+  });

  t.regex(stdout, new RegExp(`Console: Exposing token ${escapeRegExp(SECRET_REPLACEMENT)}`));
  t.regex(stdout, new RegExp(`Log: Exposing token ${escapeRegExp(SECRET_REPLACEMENT)}`));
@@ -680,7 +687,7 @@ test('Use the valid git credentials when multiple are provided', async (t) => {

 test('Use the repository URL as is if none of the given git credentials are valid', async (t) => {
  const {cwd} = await gitbox.createRepo('test-invalid-auth');
-  const dummyUrl = 'http://toto@localhost:2080/git/test-auth.git';
+  const dummyUrl = 'http://toto@localhost:2080/git/test-invalid-auth.git';

  t.is(
    await getAuthUrl({