semantic-release 19.0.2 → 19.0.5

package/docs/developer-guide/plugin.md

@@ -12,9 +12,9 @@ To create a plugin for `semantic-release`, you need to decide which parts of the
 - `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 `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.
+`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecycles 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:
+In addition to the lifecycle methods, each lifecycle is passed two objects:
 
 1. `pluginConfig` - an object containing the options that a user may pass in via their `release.config.js` file (or similar)
 2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process.

package/docs/extending/plugins-list.md

@@ -55,12 +55,12 @@
 - [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker)
   - `verifyConditions`: Verify that all needed configuration is present and login to the configured docker registry.
   - `publish`: Tag the image specified by `name` with the new version and channel and push it to the configured docker registry.
-  - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry ie: next to latest.
+  - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry i.e.: next to latest.
 - [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr)
   - `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry
   - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
 - [semantic-release-vsce](https://github.com/raix/semantic-release-vsce)
-  - `verifyConditions`: Verify the presence and the validity of the vsce authentication and release configuration
+  - `verifyConditions`: Verify the presence and the validity of the "VS Code extension" authentication and release configuration
   - `prepare`: Create a `.vsix` for distribution
   - `publish`: Publish the package to the Visual Studio Code marketplace
 - [semantic-release-verify-deps](https://github.com/piercus/semantic-release-verify-deps)
@@ -84,7 +84,7 @@
   - `prepare`: Changes the version number in the `pom.xml` (or all `pom.xml` files in maven projects with multiple `pom.xml` files) and optionally creates a commit with this version number and pushes it to `master`
   - `publish`: Runs `mvn deploy` to deploy to maven central and optionally will update to next snapshot version and merge changes to development branch
 - [semantic-release-ado](https://github.com/lluchmk/semantic-release-ado)
-  - `prepare`: Stores the version number as an Azure DevOps pipeline variable availabe to downstream steps on the job
+  - `prepare`: Stores the version number as an Azure DevOps pipeline variable available to downstream steps on the job
 - [gradle-semantic-release](https://github.com/KengoTODA/gradle-semantic-release-plugin)
   - `verifyConditions`: Verify that project has a Gradle wrapper script, and `build.gradle` contains a task to publish artifacts.
   - `prepare`: Changes the version number in the `gradle.properties`
@@ -157,3 +157,12 @@
   - `verifyConditions`: Verify plugin configuration and login to Helm registry
   - `prepare`: Package Helm chart to local folder
   - `publish`: Publish Helm chart to OCI registry
+- [semantic-release-space](https://github.com/123FLO321/semantic-release-space)
+  - `verifyConditions` Verifies that all required options are set.
+  - `prepare` Creates a JetBrains Space Deployment Target if it does not yet exist.
+  - `publish` Starts a JetBrains Space Deployment.
+  - `success` Marks the JetBrains Space Deployment as completed.
+  - `fail` Marks the JetBrains Space Deployment as failed.
+- [semantic-release-react-native](https://github.com/alexandermendes/semantic-release-react-native)
+  - `verifyConditions` Validate configuration.
+  - `prepare` Version native iOS and Android files.

package/docs/extending/shareable-configurations-list.md

@@ -6,7 +6,7 @@
 
 ## Community configurations
 - [@jedmao/semantic-release-npm-github-config](https://github.com/jedmao/semantic-release-npm-github-config)
-  - Provides an informative [git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., "chore(release): 1.2.3 [skip ci]\n\nnotes").
+  - Provides an informative [Git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., `chore(release): 1.2.3 [skip ci]\n\nnotes`).
   - Creates a tarball that gets uploaded with each [GitHub release](https://github.com/semantic-release/github).
   - Publishes the same tarball to [npm](https://github.com/semantic-release/npm).
   - Commits the version change in `package.json`.
@@ -18,4 +18,3 @@
   - Updates GitHub release with release-notes.
   - Bumps a version in package.json.
   - Publishes the new version to [NPM](https://npmjs.org).
-  

package/docs/recipes/ci-configurations/circleci-workflows.md

@@ -22,14 +22,12 @@ Finally, we call our release job with a `requires` parameter so that `release` w
 ```yaml
 version: 2.1
 orbs:
-  node: circleci/node@4.5
+  node: circleci/node@5.0.0
 jobs:
   release:
     executor: node/default
     steps:
       - checkout
-      - node/install
-          lts: true
       - node/install-packages # Install and automatically cache packages
       # Run optional required steps before releasing
       # - run: npm run build-script

package/docs/recipes/ci-configurations/gitlab-ci.md

@@ -14,7 +14,7 @@ GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) all
 
 ### `.gitlab-ci.yml` configuration for Node projects
 
-This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
 
 **Note**: The`semantic-release` execution command varies depending on whether you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.
 
@@ -48,7 +48,7 @@ publish:
 
 ### `.gitlab-ci.yml` configuration for all projects
 
-This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
 
 **Note**: The`semantic-release` execution command varies depending if you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.
 
@@ -66,8 +66,8 @@ release:
     - npm install -g semantic-release @semantic-release/gitlab
   script:
     - semantic-release
-  only:
-    - master
+  rules:
+    - if: $CI_COMMIT_BRANCH == "master"
 
 release:
   image: node:12-buster-slim
@@ -77,8 +77,8 @@ release:
     - npm install -g semantic-release @semantic-release/gitlab
   script:
     - semantic-release
-  only:
-    - master
+  rules:
+    - if: $CI_COMMIT_BRANCH == "master"
 ```
 
 ### `package.json` configuration

package/docs/recipes/release-workflow/distribution-channels.md

@@ -1,6 +1,6 @@
 # Publishing on distribution channels
 
-This recipe will walk you through a simple example that uses distribution channels to make releases available only to a subset of users, in order to collect feedbacks before distributing the release to all users.
+This recipe will walk you through a simple example that uses distribution channels to make releases available only to a subset of users, in order to collect feedback before distributing the release to all users.
 
 This example uses the **semantic-release** default configuration:
 - [branches](../../usage/configuration.md#branches): `['+([0-9])?(.{+([0-9]),x}).x', 'master', 'next', 'next-major', {name: 'beta', prerelease: true}, {name: 'alpha', prerelease: true}]`

package/docs/support/FAQ.md

@@ -44,7 +44,7 @@ Yes, **semantic-release** is a Node CLI application, but it can be used to publi
 
 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)
+- 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 a version of Node that [meets our version requirement](./node-version.md) to execute the `semantic-release` command
 
 See the [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on specific CI environments.
@@ -153,7 +153,7 @@ Any npm compatible registry is supported with the [`@semantic-release/npm`](http
 
 See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details.
 
-See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactiry configuration.
+See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactory configuration.
 
 ## Can I manually trigger the release of a specific version?
 

package/docs/support/node-version.md

@@ -1,6 +1,6 @@
 # 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 14.17 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 14.17 or higher**.
 
 **semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency.
 Therefore, the only constraint is to run the `semantic-release` in a CI environment providing version of Node that meets our version requirement.

package/docs/usage/ci-configuration.md

@@ -13,7 +13,7 @@ Here is a few example of the CI services that can be used to achieve this:
 - [Wercker Workflows](http://devcenter.wercker.com/docs/workflows)
 - [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline).
 
-See [CI configuration recipes](../recipes/ci-configurations/README.md) for more details.
+See [CI configuration recipes](../recipes/ci-configurations#ci-configurations) for more details.
 
 ## Authentication
 
@@ -26,7 +26,7 @@ See [CI configuration recipes](../recipes/ci-configurations/README.md) for more
 | `GH_TOKEN` or `GITHUB_TOKEN`                          | A GitHub [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line).                                                                                                    |
 | `GL_TOKEN` or `GITLAB_TOKEN`                          | A GitLab [personal access token](https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html).                                                                                                                       |
 | `BB_TOKEN` or `BITBUCKET_TOKEN`                       | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html).                                                                                                 |
-| `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clearification `user:token` has to be the value of this env.        |
+| `BB_TOKEN_BASIC_AUTH` or `BITBUCKET_TOKEN_BASIC_AUTH` | A Bitbucket [personal access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) with basic auth support. For clarification `user:token` has to be the value of this env.        |
 | `GIT_CREDENTIALS`                                     | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `<username>:<password>`. The username and password must each be individually URL encoded, not the `:` separating them. |
 
 Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-hosted-services/git-auth-ssh-keys.md).
@@ -44,6 +44,6 @@ See each plugin's documentation for the environment variables required.
 
 The authentication token/credentials have to be made available in the CI service via environment variables.
 
-See [CI configuration recipes](../recipes/ci-configurations/README.md) for more details on how to configure environment variables in your CI service.
+See [CI configuration recipes](../recipes/ci-configurations#ci-configurations) for more details on how to configure environment variables in your CI service.
 
 **Note**: The environment variables `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN` and `GITLAB_TOKEN` can be used for both the Git authentication and the API authentication required by [@semantic-release/github](https://github.com/semantic-release/github) and [@semantic-release/gitlab](https://github.com/semantic-release/gitlab).

package/docs/usage/configuration.md

@@ -69,8 +69,8 @@ The branches on which releases should happen. By default **semantic-release** wi
 - regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range (`N.N.x` or `N.x.x` or `N.x` with `N` being a number)
 - regular releases to the `next` distribution channel from the branch `next` if it exists
 - regular releases  to the `next-major` distribution channel from the branch `next-major` if it exists
-- prereleases to the `beta` distribution channel from the branch `beta` if it exists
-- prereleases to the `alpha` distribution channel from the branch `alpha` if it exists
+- pre-releases to the `beta` distribution channel from the branch `beta` if it exists
+- pre-releases to the `alpha` distribution channel from the branch `alpha` if it exists
 
 **Note**: If your repository does not have a release branch, then **semantic-release** will fail with an `ERELEASEBRANCHES` error message. If you are using the default configuration, you can fix this error by pushing a `master` branch.
 
@@ -116,7 +116,7 @@ Type: `Boolean`<br>
 Default: `false` if running in a CI environment, `true` otherwise<br>
 CLI arguments: `-d`, `--dry-run`
 
-The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, success and fail. In addition to this it prints the next version and release notes to the console.
+The objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, addChannel, success and fail. In addition to this it prints the next version and release notes to the console.
 
 **Note**: The Dry-run mode verifies the repository push permission, even though nothing will be pushed. The verification is done to help user to figure out potential configuration issues.
 

package/index.js

@@ -75,7 +75,7 @@ async function run(context, plugins) {
   }
 
   logger[options.dryRun ? 'warn' : 'success'](
-    `Run automated release from branch ${ciBranch} on repository ${options.repositoryUrl}${
+    `Run automated release from branch ${ciBranch} on repository ${options.originalRepositoryURL}${
       options.dryRun ? ' in dry-run mode' : ''
     }`
   );
@@ -263,6 +263,7 @@ module.exports = async (cliOptions = {}, {cwd = process.cwd(), env = process.env
   context.logger.log(`Running ${pkg.name} version ${pkg.version}`);
   try {
     const {plugins, options} = await getConfig(context, cliOptions);
+    options.originalRepositoryURL = options.repositoryUrl;
     context.options = options;
     try {
       const result = await run(context, plugins);

package/lib/branches/index.js

@@ -27,6 +27,7 @@ module.exports = async (repositoryUrl, ciBranch, context) => {
 
   const errors = [];
   const branchesByType = Object.entries(DEFINITIONS).reduce(
+    // eslint-disable-next-line unicorn/no-fn-reference-in-iterator
     (branchesByType, [type, {filter}]) => ({[type]: branches.filter(filter), ...branchesByType}),
     {}
   );

package/lib/definitions/branches.js

@@ -16,6 +16,7 @@ const prerelease = {
 };
 
 const release = {
+  // eslint-disable-next-line unicorn/no-fn-reference-in-iterator
   filter: (branch) => !maintenance.filter(branch) && !prerelease.filter(branch),
   branchesValidator: (branches) => branches.length <= 3 && branches.length > 0,
 };

package/lib/get-git-auth-url.js

@@ -89,7 +89,7 @@ module.exports = async (context) => {
   try {
     debug('Verifying ssh auth by attempting to push to  %s', repositoryUrl);
     await verifyAuth(repositoryUrl, branch.name, {cwd, env});
-  } catch (_) {
+  } catch {
     debug('SSH key auth failed, falling back to https.');
     const envVars = Object.keys(GIT_TOKENS).filter((envVar) => !isNil(env[envVar]));
 

package/lib/git.js

@@ -116,7 +116,7 @@ async function fetch(repositoryUrl, branch, ciBranch, execaOptions) {
       ],
       execaOptions
     );
-  } catch (_) {
+  } catch {
     await execa(
       'git',
       [
@@ -144,7 +144,7 @@ async function fetchNotes(repositoryUrl, execaOptions) {
       ['fetch', '--unshallow', repositoryUrl, `+refs/notes/${GIT_NOTE_REF}:refs/notes/${GIT_NOTE_REF}`],
       execaOptions
     );
-  } catch (_) {
+  } catch {
     await execa('git', ['fetch', repositoryUrl, `+refs/notes/${GIT_NOTE_REF}:refs/notes/${GIT_NOTE_REF}`], {
       ...execaOptions,
       reject: false,

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "semantic-release",
   "description": "Automated semver compliant package publishing",
-  "version": "19.0.2",
+  "version": "19.0.5",
   "author": "Stephan Bönnemann <stephan@boennemann.me> (http://boennemann.me)",
   "ava": {
     "files": [
@@ -57,7 +57,7 @@
     "dockerode": "3.3.1",
     "file-url": "3.0.0",
     "fs-extra": "9.1.0",
-    "got": "11.8.3",
+    "got": "11.8.5",
     "js-yaml": "4.1.0",
     "mockserver-client": "5.11.2",
     "nock": "13.2.1",
@@ -67,7 +67,7 @@
     "sinon": "12.0.1",
     "stream-buffers": "3.0.2",
     "tempy": "1.0.1",
-    "xo": "0.29.1"
+    "xo": "0.32.1"
   },
   "engines": {
     "node": ">=16 || ^14.17"
@@ -129,6 +129,7 @@
     "prettier": true,
     "space": true,
     "rules": {
+      "unicorn/no-reduce": "off",
       "unicorn/string-content": "off"
     }
   },