fix(marked): reverted upgrade to v3 (#2087)

since marked v3 requires node v12

.github/workflows/release.yml

@@ -0,0 +1,23 @@
+name: Release
+on:
+  push:
+    branches:
+      - master
+      - next
+      - beta
+      - "*.x" # maintenance releases branches
+
+jobs:
+  release:
+    name: release
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2
+        with:
+          cache: npm
+      - run: npm ci
+      - run: npx semantic-release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.SEMANTIC_RELEASE_BOT_NPM_TOKEN }}

.github/workflows/test.yml

@@ -0,0 +1,51 @@
+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:
+          - 10.18.0
+          - 12
+          - 14
+
+    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
+      - name: Ensure dependencies are compatible with the version of node
+        run: echo 'engine-strict=true' >> .npmrc
+      - 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:
+          cache: npm
+      - run: npm ci
+      - run: npm run lint

.gitignore

@@ -125,10 +125,6 @@ $RECYCLE.BIN/
 # Windows shortcuts
 *.lnk
 
-# Lockfiles
-package-lock.json
-yarn.lock
-
 # Gitbook
 _book
 

.npmrc

@@ -1 +0,0 @@
-package-lock=false

.travis.yml

@@ -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

.travis/codecov.yml

@@ -1,2 +0,0 @@
-after_success:
-  - npm run codecov

.travis/greenkeeper.yml

@@ -1,3 +0,0 @@
-branches:
-  only:
-    - /^greenkeeper.*$/

.travis/node-versions.yml

@@ -1,3 +0,0 @@
-node_js:
-  - 12
-  - 10.18

.travis/node.yml

@@ -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

.travis/semantic-release.yml

@@ -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

.yarnrc

@@ -1 +0,0 @@
---install.no-lockfile true

README.md

@@ -1,17 +1,11 @@
 <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">
@@ -54,14 +48,14 @@ This removes the immediate connection between human emotions and version numbers
 
 **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.
 
-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              |
 | `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 |
@@ -75,6 +69,7 @@ Here is an example of the release type that will be done based on a commit messa
 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.
 
 **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)
@@ -84,7 +79,7 @@ For each new commits added to one of the release branches (for example `master`,
 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,6 +93,7 @@ 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
@@ -135,7 +131,7 @@ In order to use **semantic-release** you need:
 ## Get help
 
 - [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release)
-- [Spectrum community](https://spectrum.chat/semantic-release)
+- [GitHub Discussions](https://github.com/semantic-release/semantic-release/discussions)
 - [Twitter](https://twitter.com/SemanticRelease)
 
 ## Badge
@@ -160,7 +156,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>

bin/semantic-release.js

@@ -40,6 +40,7 @@ require('../cli')()
   .then((exitCode) => {
     process.exitCode = exitCode;
   })
-  .catch(() => {
+  .catch((error) => {
+    console.error(error);
     process.exitCode = 1;
   });

docs/README.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
+- [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
 - [Developer Guide](developer-guide/README.md) - The essentials of writing a **semantic-release** plugin or shareable configurations
 - [Support](support/README.md) - FAQ and troubleshooting

docs/developer-guide/plugin.md

@@ -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:
 
@@ -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,33 @@ Similar to `options`, environment variables exist to allow users to pass tokens
 const { env } = context;
 
 if (env.GITHUB_TOKEN) {
-    //...
+  //...
 }
-```
+```
+
+## 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.

docs/extending/plugins-list.md

@@ -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,9 @@
 - [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, push it to the configured docker registry and update the `latest`, `major`, `minor` tags based on the configuration settings.
 - [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 +94,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 +130,13 @@
   - `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

docs/recipes/circleci-workflows.md

@@ -10,46 +10,39 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with
 
 ### `.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 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.
 
-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).
+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 only run after `node/test` has successfully tested against v14 and v16.
 
 ```yaml
-version: 2
+version: 2.1
+orbs:
+  node: circleci/node@4.5
 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
+    executor: node/default
     steps:
       - checkout
-      - run: npm install
+      - node/install-packages # Install and automatically cache packages
       # 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
+      - node/test:
+          matrix:
+            parameters:
+              version:
+                - 16.1.0
+                - 14.7.0
       - release:
           requires:
-            - test_node_6
-            - test_node_8
+            - node/test
 ```
 
 ### `package.json` configuration for multiple Node jobs

docs/recipes/distribution-channels.md

@@ -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:
 

docs/recipes/github-actions.md

@@ -25,7 +25,7 @@ on:
 jobs:
   release:
     name: Release
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-latest
     steps:
       - name: Checkout
         uses: actions/checkout@v2
@@ -50,7 +50,7 @@ To keep `package.json` updated in the `master` branch, [`@semantic-release/git`]
 
 **Note**: Automatically populated `GITHUB_TOKEN` cannot be used if branch protection is enabled for the target branch. It is **not** advised to mitigate this limitation by overriding an automatically populated `GITHUB_TOKEN` variable with a [Personal Access Tokens](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line), as it poses a security risk. Since Secret Variables are available for Workflows triggered by any branch, it becomes a potential vector of attack, where a Workflow triggered from a non-protected branch can expose and use a token with elevated permissions, yielding branch protection insignificant. One can use Personal Access Tokens in trusted environments, where all developers should have the ability to perform administrative actions in the given repository and branch protection is enabled solely for convenience purposes, to remind about required reviews or CI checks.
 
-If the risk is acceptible, some extra configuration is needed. The [actions/checkout `persist-credentials`](https://github.com/marketplace/actions/checkout#usage) option needs to be `false`, otherwise the generated `GITHUB_TOKEN` will interfere with the custom one. Example:
+If the risk is acceptable, some extra configuration is needed. The [actions/checkout `persist-credentials`](https://github.com/marketplace/actions/checkout#usage) option needs to be `false`, otherwise the generated `GITHUB_TOKEN` will interfere with the custom one. Example:
 
 ```yaml
 - name: Checkout

docs/recipes/maintenance-releases.md

@@ -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.
 

docs/support/FAQ.md

@@ -8,7 +8,7 @@ By default, only the published package will contain the version, which is the on
 
 However, the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin can be used to push the updated `package.json` as well as other files to the Git repository.
 
-If you wish to only update the `package.json` and push via Git you can set the project to `"private": true,` within your `package.json` to prevent publishing to [npm](https://www.npmjs.com). This can be useful for using **semantic-release** with a non-node project.
+If you wish to only update the `package.json` and push via Git you can set the project to `"private": true,` within your `package.json` to prevent publishing to [the npm registry](https://www.npmjs.com).
 
 ## How can I use a npm build script that requires the `package.json`’s version ?
 

docs/support/resources.md

@@ -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
 

docs/support/troubleshooting.md

@@ -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.

docs/usage/ci-configuration.md

@@ -8,7 +8,7 @@ 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).

docs/usage/plugins.md

@@ -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.

docs/usage/workflow-configuration.md

@@ -13,7 +13,7 @@ Each branch can be defined either as a string, a [glob](https://github.com/micro
 
 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
 
@@ -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.

lib/definitions/errors.js

@@ -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)}\`.`,
   }),

lib/get-config.js

@@ -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);
 

lib/git.js

@@ -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.

package.json

@@ -26,19 +26,19 @@
     "@semantic-release/npm": "^7.0.0",
     "@semantic-release/release-notes-generator": "^9.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": "^2.0.0",
+    "marked-terminal": "^4.1.1",
     "micromatch": "^4.0.2",
     "p-each-series": "^2.1.0",
     "p-reduce": "^2.0.0",
@@ -47,27 +47,27 @@
     "semver": "^7.3.2",
     "semver-diff": "^3.1.1",
     "signale": "^1.2.1",
-    "yargs": "^15.0.1"
+    "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.1",
+    "codecov": "3.8.2",
+    "delay": "5.0.0",
+    "dockerode": "3.3.0",
+    "file-url": "3.0.0",
+    "fs-extra": "10.0.0",
+    "got": "11.8.2",
+    "js-yaml": "4.1.0",
+    "mockserver-client": "5.11.2",
+    "nock": "13.1.1",
+    "nyc": "15.1.0",
+    "p-retry": "4.6.1",
+    "proxyquire": "2.1.3",
+    "sinon": "11.1.1",
+    "stream-buffers": "3.0.2",
+    "tempy": "1.0.1",
+    "xo": "0.29.1"
   },
   "engines": {
     "node": ">=10.18"
@@ -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"
+    ]
   }
 }

test/get-config.test.js

@@ -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();

test/helpers/git-utils.js

@@ -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};
 }

test/helpers/gitbox.js

@@ -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};

test/integration.test.js

@@ -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({