fix(engines): fixed defined node version to account for the higher requirement from the npm plugin (#2088 )

fix(marked): reverted upgrade to v3 (#2087 )
since marked v3 requires node v12
2021-08-25 12:01:16 -07:00 · 2021-08-23 15:34:58 -05:00 · 2021-08-15 22:58:06 -07:00 · 2021-08-11 23:11:48 -05:00 · 2021-07-19 13:17:04 -07:00 · 2021-07-19 10:39:55 -07:00
42 changed files with 14062 additions and 255 deletions
@@ -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 }}
@@ -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.19.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
+      - 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
+      - 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
@@ -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,10 +93,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
+- [Node.js](https://nodejs.org) version [10.19 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1019) installed in your Continuous Integration environment

 ## Documentation

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

@@ -10,11 +10,11 @@ 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 [Node version >= 10.19](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).

 ### `.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 Node 10.19 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,7 +25,7 @@ on:
 jobs:
  release:
    name: Release
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
@@ -34,7 +34,7 @@ jobs:
      - name: Setup Node.js
        uses: actions/setup-node@v1
        with:
-          node-version: 12
+          node-version: '10.19'
      - name: Install dependencies
        run: npm ci
      - name: Release
@@ -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
@@ -10,7 +10,7 @@ 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 >= 10.19 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).

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

@@ -54,7 +54,7 @@ This example is a minimal configuration for **semantic-release** with a build ru


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

@@ -10,7 +10,7 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with

 ### `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 >= 10.19 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).

 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.

@@ -19,7 +19,7 @@ The`semantic-release` execution command varies depending if you are using a [loc
 ```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')
    }
@@ -35,14 +35,14 @@ pipeline {
        }
        stage('Release') {
            tools {
-            nodejs "node 10.18"
+            nodejs "node 10.19"
            }
            steps {
                sh '''
                # Run optional required steps before releasing
                npx semantic-release
                '''
-            }            
+            }
        }
    }
 }
@@ -58,4 +58,4 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
    "semantic-release": "^15.0.0"
  }
 }
-```
+```
@@ -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.

@@ -10,7 +10,7 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with

 ### `.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 10 and 12. 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).

@@ -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
+  - 10
+  - 12

 jobs:
  include:
@@ -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 ?

@@ -38,44 +38,14 @@ 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 [Node >= 10.19](#why-does-semantic-release-require-node-version--1019) to execute the `semantic-release` command

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

@@ -234,9 +204,9 @@ See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/i

 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?
+## Why does semantic-release require Node version >= 10.19?

-**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**.
+**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.19 or higher**.

 See [Node version requirement](./node-version.md#node-version-requirement) for more details and solutions.

@@ -1,6 +1,6 @@
 # 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 only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 10.19 (LTS)](https://nodejs.org/en/blog/release/v10.19.0).

 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.

@@ -1,16 +1,16 @@
 # 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 Node version 10.19 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 Node 10.19 or higher.

 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 Node >= 10.19

-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 Node 10.19 or higher. This can either be a job used by your project to test on Node >= 10.19 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.

@@ -18,18 +18,18 @@ See [CI configuration](../usage/ci-configuration.md) and [CI configuration recip

 ### Use `npx`

-`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 10 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@10 -c "npx semantic-release"
 ```

 **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 Node 10.19 before running the `semantic-release` command.

 ```bash
-$ nvm install 8 && npx semantic-release
+$ nvm install 10.19 && 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,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).
@@ -24,6 +24,6 @@ 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 with `npx semantic-release@17`). 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.
@@ -12,9 +12,12 @@ A plugin is a npm module that can implement one or more of the following steps:
 | `generateNotes`    | No       | Responsible for generating the content of the release note. If multiple plugins with a `generateNotes` step are defined, the release notes will be the result of the concatenation of each plugin output.            |
 | `prepare`          | No       | Responsible for preparing the release, for example creating or updating files such as `package.json`, `CHANGELOG.md`, documentation or compiled assets and pushing a commit.                                         |
 | `publish`          | No       | Responsible for publishing the release.                                                                                                                                                                              |
+| `addChannel`       | No       | Responsible for adding a release channel (e.g. adding an npm dist-tag to a release).                                                                                                                                 |
 | `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
@@ -69,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.
@@ -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.
@@ -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,27 +9,15 @@ 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);

  // Merge config file options and CLI/API options
  let options = {...config, ...cliOptions};
-  if (options.ci === false) {
-    options.noCi = true;
-  }

  const pluginsPath = {};
  let extendPaths;
@@ -87,6 +75,10 @@ module.exports = async (context, cliOptions) => {
    ...(options.branches ? {branches: castArray(options.branches)} : {}),
  };

+  if (options.ci === false) {
+    options.noCi = true;
+  }
+
  debug('options values: %O', options);

  return {options, plugins: await plugins({...context, options}, pluginsPath)};
@@ -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.
@@ -1,8 +1,3 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<svg width="530px" height="500px" viewBox="0 0 530 500" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-    <title>semantic-release-logo</title>
-    <desc>Created with Sketch.</desc>
-    <g id="semantic-release-logo" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
-        <path d="M265,300 C237.385763,300 215,277.614237 215,250 C215,222.385763 237.385763,200 265,200 C292.614237,200 315,222.385763 315,250 C315,277.614237 292.614237,300 265,300 Z M265,285 C284.329966,285 300,269.329966 300,250 C300,230.670034 284.329966,215 265,215 C245.670034,215 230,230.670034 230,250 C230,269.329966 245.670034,285 265,285 Z M189.000329,65.2403903 C188.735843,74.8097173 187.789784,91.8126705 189.063568,101.364143 C190.525406,112.325741 210.229645,156.413574 224,182.11536 C205.822021,168.897491 166.460815,138.916283 154.532196,124.016029 C144.386757,111.343179 140.471577,101.013967 138.27655,94.5257779 L67.4936491,135.392305 L67.4936491,221.416812 C75.70945,226.485387 89.6365324,235.558433 98.3968671,239.169872 C108.620808,243.384682 156.654111,248.364228 185.797688,249.289643 C165.261689,258.4233 119.616597,277.5205 100.74829,280.400861 C85.0249878,282.801118 74.2405506,281.146683 67.4936491,279.815488 L67.4936491,364.607695 L136.385575,404.382467 C144.921121,399.789873 159.526093,392.355786 166.960336,386.631446 C175.722439,379.884659 204.051503,340.77637 219.424725,316 C217.066704,338.351526 210.782819,387.429934 203.843131,405.210548 C198.129099,419.850831 191.397729,428.335995 186.871704,433.530648 L266,479.21539 L339.488885,436.786563 C339.680455,427.59622 340.80544,409.239923 339.462313,399.168483 C338.000475,388.206886 318.296236,344.119052 304.525881,318.417266 C322.70386,331.635135 362.065066,361.616344 373.993685,376.516597 C384.808925,390.026108 388.544108,400.872311 390.662883,407.241241 L464.506351,364.607695 L464.506351,280.839881 C456.814912,276.224155 441.003684,265.702718 431.400821,261.743946 C421.17688,257.529136 373.143577,252.549591 344,251.624176 C364.535999,242.490519 410.181091,223.393319 429.049398,220.512958 C446.610988,217.832076 458.01135,220.209416 464.506351,221.544989 L464.506351,135.392305 L395.40349,95.4957494 C387.052842,100.028294 371.568068,107.82975 363.837352,113.782373 C355.075249,120.52916 326.746185,159.637448 311.372963,184.413819 C313.730984,162.062293 320.014869,112.983884 326.954557,95.2032704 C332.946763,79.8502605 340.057772,71.2662505 344.570949,66.147568 L266,20.7846097 L189.000329,65.2403903 L189.000329,65.2403903 Z M266,0 L482.506351,125 L482.506351,375 L266,500 L49.4936491,375 L49.4936491,125 L266,0 Z" id="semantic-release-logo-shape" fill="#494949" fill-rule="nonzero"></path>
-    </g>
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="15 0 500 500" width="500px" height="500px">
+    <path fill="#494949" fill-rule="nonzero" d="M265 300a50 50 0 110-100 50 50 0 010 100zm0-15a35 35 0 100-70 35 35 0 000 70zM189 65v36c2 11 21 55 35 81-18-13-58-43-69-58a92 92 0 01-17-29l-71 40v86c9 5 23 15 31 18 11 4 59 9 88 10-21 9-66 29-85 31-16 3-27 1-34 0v85l69 39c9-4 24-12 31-17 9-7 37-46 52-71-2 22-8 71-15 89-6 15-13 23-17 29l79 45 73-42c1-9 2-28 0-38-1-11-21-55-34-81 18 14 57 44 69 59 11 13 15 24 17 30l74-42v-84c-8-5-24-15-34-19s-58-9-87-10c21-10 66-29 85-31 18-3 29-1 36 1v-87l-70-40-31 19c-9 7-37 46-53 70 3-22 9-71 16-89 6-15 13-24 18-29l-79-45-77 44zm77-65l217 125v250L266 500 49 375V125L266 0z"/>
 </svg>
@@ -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,30 +47,30 @@
    "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": "9.1.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"
+    "node": ">=10.19"
  },
  "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();
@@ -505,10 +549,10 @@ test('Allow to unset properties defined in shareable config with "undefined"', a
 test('Throw an Error if one of the shareable config cannot be found', async (t) => {
  // Create a git repository, set the current working directory at the root of the repo
  const {cwd} = await gitRepo();
-  const pkhOptions = {extends: ['./shareable1.json', 'non-existing-path']};
+  const pkgOptions = {extends: ['./shareable1.json', 'non-existing-path']};
  const options1 = {analyzeCommits: 'analyzeCommits'};
  // Create package.json and shareable.json in repository root
-  await outputJson(path.resolve(cwd, 'package.json'), {release: pkhOptions});
+  await outputJson(path.resolve(cwd, 'package.json'), {release: pkgOptions});
  await outputJson(path.resolve(cwd, 'shareable1.json'), options1);

  await t.throwsAsync(t.context.getConfig({cwd}), {
@@ -516,3 +560,20 @@ test('Throw an Error if one of the shareable config cannot be found', async (t)
    code: 'MODULE_NOT_FOUND',
  });
 });
+
+test('Convert "ci" option to "noCi" when set from extended config', async (t) => {
+  // Create a git repository, set the current working directory at the root of the repo
+  const {cwd} = await gitRepo();
+  const pkgOptions = {extends: './no-ci.json'};
+  const options = {
+    ci: false,
+  };
+  // Create package.json and shareable.json in repository root
+  await outputJson(path.resolve(cwd, 'package.json'), {release: pkgOptions});
+  await outputJson(path.resolve(cwd, 'no-ci.json'), options);
+
+  const {options: result} = await t.context.getConfig({cwd});
+
+  t.is(result.ci, false);
+  t.is(result.noCi, true);
+});
@@ -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};
@@ -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({
Author	SHA1	Message	Date
Matt TraviandGitHub	ea52e1775a	fix(engines): fixed defined node version to account for the higher requirement from the npm plugin (#2088 )	2021-08-25 12:01:16 -07:00
Matt TraviandGitHub	5edff69580	fix(marked): reverted upgrade to v3 (#2087 ) since marked v3 requires node v12	2021-08-23 15:34:58 -05:00
renovate[bot]GitHub Renovate Bot	6e4beb8314	fix(deps): update dependency marked to v3 Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-08-15 22:58:06 -07:00
renovate[bot]GitHub Renovate Bot	ebad322318	chore(deps): update dependency path-parse to 1.0.7 [security] (#2072 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-08-11 23:11:48 -05:00
renovate[bot]GitHub Renovate Bot	88e423b828	chore(deps): update dependency p-retry to v4.6.1 (#2042 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-07-19 13:17:04 -07:00
Oscar DominguezandGitHub	a4f0ff70fe	ci(workflow): add 'npm' cache for actions/setup-node in .github/workflows (#2038 )	2021-07-19 10:39:55 -07:00
renovate[bot]GitHub Renovate Bot	ee3068eb6a	chore(deps): update dependency nock to v13.1.1 (#2034 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-07-18 10:06:40 -07:00
Hugh RawlinsonandGitHub	04b6046e1f	docs(branches): minor typo fixes (#2033 )	2021-07-17 14:53:43 -07:00
renovate[bot]GitHub Renovate Bot	fa847e2b87	chore(deps): update dependency p-retry to v4.6.0 (#2004 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-07-08 21:39:19 +00:00
Kyle TandGitHub	413ffd2a4b	docs(circleci): Update CircleCI recipes config (#2018 ) Updates the included CircleCI config file example. * Now uses 2.1 style config * Uses Node Orb * Use pre-defined node/test job * Uses Matrix jobs to test multiple node versions. * Updated Node versions * Using new CircleCI docker images (from node executor) * Updated language/terminology in description	2021-07-08 13:14:29 -07:00
renovate[bot]GitHub Renovate Bot Matt Travi	143c8981bf	chore(deps): update dependency js-yaml to v4 (#1752 ) Co-authored-by: Renovate Bot <bot@renovateapp.com> Co-authored-by: Matt Travi <programmer@travi.org>	2021-07-02 00:07:46 -05:00
Moritz WiesingerandGitHub	cf000687c4	docs(recipes): fix some typos (#1999 ) Signed-off-by: Moritz Wiesinger <moritz.wiesinger@dynatrace.com>	2021-07-01 09:17:34 -07:00
Fernando RojoandGitHub	1463eb42cb	docs(plugins): clarify order of execution (#1989 )	2021-06-25 14:06:57 -05:00
AxieumandGitHub	80e1665037	fix: corrected spelling of invalid plugin config error (#1979 )	2021-06-15 09:52:19 -05:00
renovate[bot]GitHub Renovate Bot	37765ef36d	chore(deps): update dependency dockerode to v3.3.0 (#1977 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-06-11 08:56:45 -07:00
renovate[bot]GitHub Renovate Bot	a7a1e6d28f	chore(deps): update dependency sinon to v11 (#1976 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-06-11 13:38:45 +00:00
renovate[bot]GitHub Renovate Bot	59bf862d4a	chore(deps): update dependency nock to v13.1.0 (#1975 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-06-10 12:45:53 -07:00
renovate[bot]GitHub Renovate Bot	78a63a7de0	chore(deps): update dependency trim-newlines to 3.0.1 [security] (#1974 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-06-08 22:31:00 -05:00
dependabot[bot]GitHub Katholische_Jugend_Fuerth_Lautenbach	61f94c00ab	build(deps): bump normalize-url from 4.5.0 to 4.5.1 (#1973 ) Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>	2021-06-08 22:03:00 -05:00
Justin DietzandGitHub	7452eaf2cd	docs: adds updated docker plugin that supports major, minor tagging (#1963 )	2021-06-03 09:31:49 -07:00
renovate[bot]GitHub Renovate Bot	c229888cc0	chore(deps): update dependency fs-extra to v10 (#1955 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-06-01 22:14:25 +00:00
HonkingGooseandGitHub	29d34788ff	docs(README): improve sentence (#1962 )	2021-06-01 13:48:53 -07:00
Aki MäkinenandGitHub	fe0ac417cf	docs(plugin developer guide): correction, additional details / advanced (#1961 ) A correction to the earlier documentation: the "nextRelease" object is NOT similar to the lastRelease and there are some differences. Because of this, the object is now documented as a separate entry. Added also information on how the error handling should be done so that semantic-release would be able to handle errors from plugins properly and call "fail" lifecycle plugins. Included some more advanced information on how the analyzeCommits-lifecycle plugins work and how the result of the initial analyzer can be overridden. This is an edge case, but could happen and is good to understand.	2021-05-31 10:15:47 -07:00
renovate[bot]GitHub Renovate Bot	3edc917c7c	chore(deps): update dependency tempy to v1.0.1 (#1946 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-05-27 02:54:20 +00:00
renovate[bot]GitHub Renovate Bot	8bc98c33c9	chore(deps): update dependency browserslist to 4.16.5 [security] (#1954 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-05-26 20:46:59 -05:00
Josh SullivanandGitHub	6427210b83	docs(workflow-configurator): fix single typo (#1892 )	2021-05-26 10:57:54 -07:00
renovate[bot]GitHub Renovate Bot	4c1c992869	chore(deps): update dependency sinon to v10 (#1941 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-05-22 01:06:53 +00:00
renovate[bot]GitHub Renovate Bot	a3a9907368	chore(deps): update dependency codecov to v3.8.2 (#1940 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-05-21 23:16:45 +00:00
Dmytro Pustovit GitHub Gregor Martynus	7fbab56a98	docs: add semantic-release-telegram to the list of community plugins (#1945 ) Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>	2021-05-21 14:30:44 -07:00
Dmytro PustovitandGitHub	7dae2a9f43	docs: add heroku to list of community plugins (#1920 )	2021-05-21 14:29:28 -07:00
Ryan SonshineandGitHub	13f6a725a1	docs(plugins-list): add semantic-release-codeartifact (#1939 )	2021-05-17 07:50:18 -07:00
Gregor MartynusandGitHub	55194c106e	fix: bump minimal version of lodash to address `CVE-2021-23337` (#1931 )	2021-05-12 11:37:06 -07:00
mhagnumdwandGitHub	e24ef71e33	docs(distribution-channels): fix branch name (#1925 )	2021-05-09 22:40:32 -05:00
Aki MäkinenandGitHub	0435e35fee	docs(Plugin Developer Guide): More detailed lifecycle list and context descriptions (#1880 ) * docs(Plugin Developer Guide): More detailed lifecycle list and context descriptions This commit will improve the following in the Plugin developer guide: * Lifecyle list more complete (previous was missing some lifecycles) * Context object has been now described in more detail per lifecycle * Some readability/maintainability fixes to the markdown file itself to make it easier to edit and read in an editor. * docs(Plugin Developer Guide): Added missing context field to analyzeCommits lifecycle documentation analyzeCommits lifecycle context was missing documentation for "commits" list. * docs(developer-guide): remove line breaks added in an earlier commit As per requested in the code review, the line breaks that were added in an earlier commit are now removed. While this does make reading the text just slightly more difficult (to see the whole picture), the benefit of making code reviews easier does outweight the admittedly small benefit.	2021-04-25 15:14:03 -07:00
renovate[bot]GitHub Renovate Bot	1d1b52a7dc	chore(deps): update dependency p-retry to v4.5.0 (#1885 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-04-10 14:57:32 +00:00
Aki MäkinenandGitHub	72522c3570	docs(Plugin Developer Guide): Update lifecycle list (#1874 ) The old list was missing analyzeCommits lifecycle and the verification lifecycle was incorrectly listed as "verify", when it should currently be "verifyConditions" in order to properly load.	2021-04-07 14:47:41 -07:00
Oscar DominguezandGitHub	5489489dda	docs(github-actions): example suggests using ubuntu-latest (#1867 ) instead of a concrete version of Ubuntu	2021-03-31 10:39:08 -07:00
Mohammed ragab aliandGitHub	12337175c6	docs: Add article to explain semantic release (#1856 )	2021-03-30 10:32:07 -07:00
renovate[bot]GitHub Renovate Bot Gregor Martynus	8fa4f9a750	chore(deps): lock file maintenance (#1861 ) * chore(deps): lock file maintenance * build(package): lock file Co-authored-by: Renovate Bot <bot@renovateapp.com> Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>	2021-03-30 10:12:16 -07:00
renovate[bot]GitHub Renovate Bot	f668935993	chore(deps): update dependency got to v11.8.2 (#1858 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-03-24 15:42:59 -07:00
renovate[bot]GitHub Renovate Bot	0f3c4148c7	chore(deps): lock file maintenance (#1848 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-03-24 19:52:13 +00:00
Kristian HeljasandGitHub	2e4b901c4f	docs: use consistent version number for tag recovery (#1857 )	2021-03-24 09:19:06 -07:00
renovate[bot]GitHub Renovate Bot	971a5e0d16	chore(deps): update dependency nock to v13.0.11 (#1844 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-03-11 15:09:05 -08:00
renovate[bot]GitHub Renovate Bot	44b3344b91	fix(deps): update dependency hosted-git-info to v4 (#1838 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-03-11 12:01:43 -08:00
renovate[bot]andGitHub	046a845a9e	chore(deps): lock file maintenance (#1835 )	2021-03-08 10:23:39 -08:00
LukasandGitHub	48def0c4cc	docs: fix links to gitlab releases documentation (#1834 )	2021-03-07 12:44:08 -08:00
Ashish Santikari GitHub Virgil	2b6c9ba093	docs: update documentation for addNote function (#1833 ) Co-Authored-By: Virgil <virgilwashere@users.noreply.github.com>	2021-03-04 16:19:31 -08:00
thislooksfunandGitHub	07f12b9df2	fix(deps): peer dependecy error with `marked-terminal` (#1829 )	2021-03-03 12:09:32 -08:00
renovate[bot]GitHub Renovate Bot Gregor Martynus	2272ce3059	chore(deps): lock file maintenance (#1826 ) * chore(deps): lock file maintenance * build(package): lock file Co-authored-by: Renovate Bot <bot@renovateapp.com> Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>	2021-03-01 10:07:51 -08:00
NickandGitHub	3ecc196d8a	feat(config): Use cosmiconfig defaults to support .cjs config files (#1815 ) This change adds support for `*.cjs` config files by removing the explicit use of `searchPlaces` options and relying and the default search places generated by `cosmicconfig`. As per the docs for [`cosmicconfig`][cc], the defaults include all the extensions/formats previously supported by semantic-release in addition to the new .cjs variants. Resolves [#1814][issue]. [issue]: https://github.com/semantic-release/semantic-release/issues/1814 [cc]: https://github.com/davidtheclark/cosmiconfig#searchplaces	2021-02-25 21:04:04 -06:00
Micael JarniacandGitHub	acf8bc4d21	docs: fix missing whitespace (#1821 )	2021-02-24 16:20:35 -08:00
Kiran KoiralaandGitHub	67dfb676bc	docs(README): change link to Angular's Contribution guidelines instead of Angular.js's Developers guide (#1817 )	2021-02-23 10:42:30 -08:00
renovate[bot]GitHub Renovate Bot	f25c3527df	chore(deps): lock file maintenance (#1813 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-22 06:51:31 +00:00
renovate[bot]GitHub Renovate Bot	6013a5633e	chore(deps): update dependency p-retry to v4.4.0 (#1803 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-15 19:43:36 +00:00
renovate[bot]GitHub Renovate Bot	d2782484c8	chore(deps): lock file maintenance (#1800 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-15 04:18:03 +00:00
renovate[bot]GitHub Renovate Bot	34e5ddad12	chore(deps): update dependency js-yaml to v3.14.1 (#1797 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-13 10:17:05 +00:00
mcnesiumandGitHub	a9be97b56b	fix: update link to GitLab CI introduction (#1794 )	2021-02-12 13:45:36 -08:00
Alexis SaettlerandGitHub	85bc213f04	docs: add semantic-release-github-pullrequest to list of community plugins (#1790 )	2021-02-11 09:09:58 -08:00
Matt TraviandGitHub	8e3a6cbef2	docs(discussions): updated spectrum references to point to discussions instead (#1782 ) for #1764	2021-02-09 08:22:21 -08:00
renovate[bot]GitHub Renovate Bot	a2eaed086f	fix(deps): update dependency marked to v2 Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-08 07:45:59 -08:00
renovate[bot]GitHub Renovate Bot	b22e591c96	chore(deps): lock file maintenance (#1779 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-08 02:04:34 +00:00
Matt TraviandGitHub	fc32afa776	build(engine-strict): strictly enforced node version compatibility for dependencies (#1763 )	2021-02-04 09:26:18 -08:00
renovate[bot]GitHub Renovate Bot	8ea81ae6c9	chore(deps): update dependency delay to v5 (#1771 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-01 10:01:31 -08:00
renovate[bot]GitHub Renovate Bot	e4002c8bd7	chore(deps): lock file maintenance (#1770 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-01 04:03:39 +00:00
renovate[bot]GitHub Renovate Bot	d738dd0fb7	chore(deps): lock file maintenance (#1769 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-02-01 01:56:15 +00:00
renovate[bot]GitHub Renovate Bot	4c7222d648	chore(deps): update dependency delay to v4.4.1 (#1768 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-30 10:47:21 +00:00
renovate[bot]GitHub Renovate Bot	54bf761f7e	chore(deps): update dependency nock to v13.0.7 (#1767 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-30 06:05:46 +00:00
renovate[bot]GitHub Renovate Bot	ea5e813192	chore(deps): lock file maintenance (#1761 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-25 23:26:59 +00:00
Gregor Martynus	a7f008253c	style: prettier	2021-01-25 13:48:03 -08:00
Gregor Martynus	ece7275743	test: bump retries in `gitbox.createRepo()` helper, see https://github.com/semantic-release/semantic-release/pull/1761\#issuecomment-767122221	2021-01-25 13:27:20 -08:00
renovate[bot]GitHub Renovate Bot	16a9fb00e9	chore(deps): update dependency sinon to v9.2.4 (#1760 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-23 13:28:47 +00:00
renovate[bot]GitHub Renovate Bot	854d643bed	chore(deps): update dependency p-retry to v4.3.0 (#1759 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-23 11:16:17 +00:00
renovate[bot]GitHub Renovate Bot	969e460948	fix(deps): update dependency get-stream to v6 (#1748 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-22 12:43:10 -08:00
Josh Soref GitHub Gregor Martynus	ab227451fa	docs: clarify renovate/** branches (#1757 ) Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: Gregor Martynus <39992+gr2m@users.noreply.github.com>	2021-01-22 11:44:54 -08:00
renovate[bot]GitHub Renovate Bot	0f37fc3aa6	chore(deps): update dependency tempy to v1 (#1755 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-21 08:33:15 +00:00
renovate[bot]GitHub Renovate Bot	fa7080e0d4	chore(deps): update dependency nock to v13 (#1754 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-21 07:00:55 +00:00
renovate[bot]GitHub Renovate Bot	0a86d61a00	chore(deps): update dependency sinon to v9.2.3 (#1750 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-21 04:05:41 +00:00
renovate[bot]GitHub Renovate Bot	d53e2066cc	chore(deps): update dependency got to v11.8.1 (#1749 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-21 03:06:00 +00:00
renovate[bot]GitHub Renovate Bot	47450fb3b1	chore(deps): update dependency fs-extra to v9.1.0 (#1747 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-20 17:04:51 -08:00
renovate[bot]GitHub Renovate Bot	fb5db83adc	chore(deps): update dependency ava to v3.15.0 (#1746 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-20 17:04:39 -08:00
renovate[bot]GitHub Renovate Bot	8262832cda	fix(deps): update dependency execa to v5 (#1745 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-20 17:00:27 -08:00
renovate[bot]GitHub Renovate Bot	cc74a4c890	fix(deps): update dependency cosmiconfig to v7 (#1742 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-20 16:59:32 -08:00
renovate[bot]GitHub Renovate Bot	a3c49428e3	chore(deps): pin dependencies (#1744 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-20 15:42:59 -08:00
renovate[bot]GitHub Renovate Bot	d95d80a0aa	chore(deps): update actions/setup-node action to v2 (#1741 ) Co-authored-by: Renovate Bot <bot@renovateapp.com>	2021-01-20 14:19:25 -08:00
Gregor Martynus GitHub Josh Soref	b5aa853b22	ci: replace travis with actions, setup renovate (#1699 ) Co-authored-by: Josh Soref <jsoref@users.noreply.github.com>	2021-01-20 14:07:16 -08:00
Josh SorefandGitHub	32a2c91d7c	fix: pin initial branch to master (#1740 )	2021-01-20 11:20:48 -08:00
Roland WeissandGitHub	d2ec8931bc	fix(deps): update to yargs 16.2.0 (#1739 ) Signed-off-by: Roland Weiss <roland.weiss@mobi.ch>	2021-01-19 08:46:14 -08:00
Thomas ZimmermannandGitHub	9f57b84aaa	fix: add logging for top-level errors (#1736 )	2021-01-15 14:31:07 -08:00
Vegard ØklandandGitHub	c5719101cc	docs: clarify node vs npm in FAQ (#1731 ) thanks @vegardok	2021-01-15 11:50:33 -08:00
Mo SattlerandGitHub	7581aa8584	docs: fix a typo in github-actions.md (#1735 )	2021-01-15 09:35:05 -06:00
Dominykas BlyžėandGitHub	21c151f167	fix: normalize ci: false into noCi: true after configs get merged (#1732 ) thanks @dominykas This makes sure that options.ci is respected even when set inside a shareable config	2021-01-13 07:38:57 -08:00
Max DuvalandGitHub	da75a9c60a	docs: clean and strip SVG logo (#1723 ) thanks @mxdvl	2021-01-04 10:48:15 -08:00
cherryblossom000andGitHub	e211499735	docs(plugins): document `addChannel` step (#1721 ) Document the `addChannel` step defined in https://github.com/semantic-release/semantic-release/blob/e35e5bb73f3628906553709ac0f5beb8f565c61a/lib/definitions/plugins.js#L83-L84, which is used in @semantic-release/npm.	2020-12-29 12:33:12 -08:00