Merge branch 'master' of github.com:semantic-release/semantic-release…

… into async-import

.github/workflows/release.yml

@@ -11,8 +11,8 @@ jobs:
     name: release
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
-      - uses: actions/setup-node@v2
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
         with:
           cache: npm
           node-version: 16

.github/workflows/test.yml

@@ -24,11 +24,11 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
       - 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
+        uses: actions/setup-node@v3
         with:
           node-version: ${{ matrix.node-version }}
           cache: npm
@@ -41,8 +41,8 @@ jobs:
     runs-on: ubuntu-latest
     needs: test_matrix
     steps:
-      - uses: actions/checkout@v2
-      - uses: actions/setup-node@v2
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
         with:
           node-version: 16
           cache: npm

docs/support/troubleshooting.md

@@ -30,7 +30,7 @@ When [squashing commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-Hist
 
 When squashing commits make sure to rewrite the resulting commit message to be compliant with the project's commit message convention.
 
-**Note**: if the resulting squashed commit would encompasses multiple changes (for example multiple unrelated features or fixes) then it's probably not a good idea to squash those commits together. A commit should contain exactly one self-contained functional change and a functional change should be contained in exactly one commit. See [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit).
+**Note**: if the resulting squashed commit encompasses multiple changes (for example multiple unrelated features or fixes) then it's probably not a good idea to squash those commits together. A commit should contain exactly one self-contained functional change and a functional change should be contained in exactly one commit. See [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit).
 
 ## `reference already exists` error when pushing tag
 
@@ -63,7 +63,7 @@ After a git history rewrite due to a `git push --force`, the git tags and notes
 
 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`.
+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 -d :[TAG NAME]`, e.g. `git push origin -d :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"]}' v2.0.0-beta.1`. If the release was also published in the default channel (usually `master`), then set the first channel to `null`, e.g. `git notes --ref semantic-release add -f -m '{"channels":[null, "beta"]}'`
 4. Push the local notes: `git push --force origin refs/notes/semantic-release`. The `--force` is needed after the rebase. Be careful.

docs/usage/ci-configuration.md

@@ -3,7 +3,7 @@
 ## Run `semantic-release` only after all tests succeeded
 
 The `semantic-release` command must be executed only after all the tests in the CI build pass. If the build runs multiple jobs (for example to test on multiple Operating Systems or Node versions) the CI has to be configured to guarantee that the `semantic-release` command is executed only after all jobs are successful.
-Here is a few example of the CI services that can be used to achieve this:
+Here are a few examples of the CI services that can be used to achieve this:
 - [Travis Build Stages](https://docs.travis-ci.com/user/build-stages)
 - [CircleCI Workflows](https://circleci.com/docs/2.0/workflows)
 - [GitHub Actions](https://github.com/features/actions)

docs/usage/configuration.md

@@ -12,8 +12,8 @@ Additionally, metadata of Git tags generated by **semantic-release** can be cust
 ## Configuration file
 
 **semantic-release**’s [options](#options), mode and [plugins](plugins.md) can be set via either:
-- A `.releaserc` file, written in YAML or JSON, with optional extensions: .`yaml`/`.yml`/`.json`/`.js`
-- A `release.config.js` file that exports an object
+- A `.releaserc` file, written in YAML or JSON, with optional extensions: `.yaml`/`.yml`/`.json`/`.js`/`.cjs`
+- A `release.config.(js|cjs)` file that exports an object
 - A `release` key in the project's `package.json` file
 
 Alternatively, some options can be set via CLI arguments.
@@ -45,7 +45,7 @@ $ semantic-release --branches next
 
 **Note**: Plugin options cannot be defined via CLI arguments and must be defined in the configuration file.
 
-**Note**: When configuring via `package.json`, the configuration must be under the `release` property. However, when using a `.releaserc` or a `release.config.js` file, the configuration must be set without a `release` property.
+**Note**: When configuring via `package.json`, the configuration must be under the `release` property. However, when using a `.releaserc` or a `release.config` file, the configuration must be set without a `release` property.
 
 ## Options
 

package.json

@@ -61,8 +61,8 @@
     "got": "11.8.5",
     "js-yaml": "4.1.0",
     "mockserver-client": "5.14.0",
-    "nock": "13.2.1",
-    "p-retry": "4.6.1",
+    "nock": "13.2.9",
+    "p-retry": "4.6.2",
     "sinon": "12.0.1",
     "stream-buffers": "3.0.2",
     "tempy": "1.0.1",