fix: add logging for when ssh falls back to http (#1639)

Co-authored-by: thomas williams <thomas.williams@thetradedesk.com>

.gitattributes

@@ -0,0 +1 @@
+* text=auto eol=lf

CONTRIBUTING.md

@@ -107,11 +107,11 @@ To ensure consistency and quality, all documentation modifications must:
   - a third-party product/brand/service, i.e. Integrate with [GitHub](https://github.com)
   - an external concept or feature, i.e. Create a [GitHub release](https://help.github.com/articles/creating-releases)
   - a package or module, i.e. The [`@semantic-release/github`](https://github.com/semantic-release/github) module
-- Use the the [single backtick `code` quoting](https://help.github.com/articles/basic-writing-and-formatting-syntax/#quoting-code) for:
+- Use the [single backtick `code` quoting](https://help.github.com/articles/basic-writing-and-formatting-syntax/#quoting-code) for:
   - commands inside sentences, i.e. the `semantic-release` command
   - programming language keywords, i.e. `function`, `async`, `String`
   - packages or modules, i.e. The [`@semantic-release/github`](https://github.com/semantic-release/github) module
-- Use the the [triple backtick `code` formatting](https://help.github.com/articles/creating-and-highlighting-code-blocks) for:
+- Use the [triple backtick `code` formatting](https://help.github.com/articles/creating-and-highlighting-code-blocks) for:
   - code examples
   - configuration examples
   - sequence of command lines

docs/extending/plugins-list.md

@@ -101,3 +101,7 @@
   - `addChannel`: Update a Gitea release's pre-release field.
 - [@google/semantic-release-replace-plugin](https://github.com/google/semantic-release-replace-plugin)
   - `prepare`: Replace version strings in files using regex and glob.
+- [semantic-release-rubygem](https://github.com/Gusto/semantic-release-rubygem)
+  - `verifyConditions`: Locate and validate a `.gemspec` file, locate and validate a `lib/**/version.rb` file, verify the presence of the `GEM_HOST_API_KEY` environment variable, and create a credentials file with the API key.
+  - `prepare`: Update the version in the `lib/**/version.rb` version file and [build](https://guides.rubygems.org/command-reference/#gem-build) the gem.
+  - `publish`: [Push the Ruby gem](https://guides.rubygems.org/command-reference/#gem-push) to the gem server. 

docs/recipes/README.md

@@ -5,6 +5,7 @@
 - [Travis CI](travis.md)
 - [GitLab CI](gitlab-ci.md)
 - [GitHub Actions](github-actions.md)
+- [Jenkins CI](jenkins-ci.md)
 
 ## Git hosted services
 - [Git authentication with SSH keys](git-auth-ssh-keys.md)

docs/recipes/github-actions.md

@@ -28,7 +28,9 @@ jobs:
     runs-on: ubuntu-18.04
     steps:
       - name: Checkout
-        uses: actions/checkout@v1
+        uses: actions/checkout@v2
+        with:
+          fetch-depth: 0
       - name: Setup Node.js
         uses: actions/setup-node@v1
         with:
@@ -48,9 +50,23 @@ 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:
+
+```yaml
+- name: Checkout
+    uses: actions/checkout@v2
+    with:
+      fetch-depth: 0
+      persist-credentials: false # <--- this
+```
+
 ## Trigger semantic-release on demand
 
-There is a way to trigger semantic-relase on demand. Use [`repository_dispatch`](https://help.github.com/en/articles/events-that-trigger-workflows#external-events-repository_dispatch) event to have control on when to generate a release by making an HTTP request, e.g.:
+### Using GUI:
+You can use [Manual Triggers](https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/) for GitHub Actions.
+
+### Using HTTP:
+Use [`repository_dispatch`](https://docs.github.com/en/actions/reference/events-that-trigger-workflows#repository_dispatch) event to have control on when to generate a release by making an HTTP request, e.g.:
 
 ```yaml
 name: Release
@@ -66,3 +82,9 @@ To trigger a release, call (with a [Personal Access Tokens](https://help.github.
 ```
 $ curl -v -H "Accept: application/vnd.github.everest-preview+json" -H "Authorization: token ${GITHUB_TOKEN}" https://api.github.com/repos/[org-name-or-username]/[repository]/dispatches -d '{ "event_type": "semantic-release" }'
 ```
+
+### Using 3rd party apps:
+If you'd like to use a GitHub app to manage this instead of creating a personal access token, you could consider using a project like:
+
+* [Actions Panel](https://www.actionspanel.app/) - A declaratively configured way for triggering GitHub Actions
+* [Action Button](https://github-action-button.web.app/#details) - A simple badge based mechanism for triggering GitHub Actions

docs/recipes/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 6 and 8. 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.
 
@@ -27,25 +27,60 @@ stages:
 before_script:
   - npm install
 
-node:6:
-  image: node:6
+node:10:
+  image: node:10
   stage: test
   script:
     - npm test
 
-node:8:
-  image: node:8
+node:12:
+  image: node:12
   stage: test
   script:
     - npm test
 
 publish:
-  image: node:8
+  image: node:12
   stage: release
   script:
     - npx semantic-release
 ```
 
+### `.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.
+
+**Note**: The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
+
+
+```yaml
+# The release pipeline will run only on the master branch a commit is triggered 
+stages:
+  - release
+
+release:
+  image: node:10-buster-slim
+  stage: release
+  before_script:
+    - apt-get update && apt-get install -y --no-install-recommends git-core ca-certificates
+    - npm install -g semantic-release @semantic-release/gitlab
+  script:
+    - semantic-release
+  only:
+    - master
+
+release:
+  image: node:12-buster-slim
+  stage: release
+  before_script:
+    - apt-get update && apt-get install -y --no-install-recommends git-core ca-certificates
+    - npm install -g semantic-release @semantic-release/gitlab
+  script:
+    - semantic-release
+  only:
+    - master
+```
+
 ### `package.json` configuration
 
 A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.

docs/recipes/jenkins-ci.md

@@ -0,0 +1,61 @@
+# Using semantic-release with [Jenkins CI](https://www.jenkins.io/doc/book/pipeline/)
+
+## Environment variables
+
+The [Authentication](../usage/ci-configuration.md#authentication) environment variables can be configured in [Jenkins Project Settings](https://www.jenkins.io/doc/pipeline/tour/environment/)..
+
+Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../usage/getting-started.md#getting-started).
+
+## Node.js project configuration
+
+### `Jenkinsfile (Declarative Pipeline)` configuration for a Node.js job
+
+**Note**: The publish pipeline must run a [Node >= 10.18 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
+
+This example is a minimal configuration for **semantic-release** with a build running Node 10.18. See [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.
+
+The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
+
+```yaml
+// The release stage in the pipeline will run only if the test stage in the pipeline is successful
+pipeline {
+    agent any 
+    environment {
+        GH_TOKEN  = credentials('some-id')
+    }
+    stages {
+        stage('Test') {
+            steps {
+                sh '''
+                # Configure your test steps here (checkout, npm install, tests etc)
+                npm install
+                npm test
+                '''
+                }
+        }
+        stage('Release') {
+            tools {
+            nodejs "node 10.18"
+            }
+            steps {
+                sh '''
+                # Run optional required steps before releasing
+                npx semantic-release
+                '''
+            }            
+        }
+    }
+}
+```
+
+### `package.json` configuration for a Node job
+
+A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
+
+```json
+{
+  "devDependencies": {
+    "semantic-release": "^15.0.0"
+  }
+}
+```

docs/support/FAQ.md

@@ -2,12 +2,14 @@
 
 ## Why is the `package.json`’s version not updated in my repository?
 
-**semantic-release** takes care of updating the `package.json`’s version before publishing to [npm](https://www.npmjs.com).
+[`@semantic-release/npm`](https://github.com/semantic-release/npm) takes care of updating the `package.json`’s version before publishing to [npm](https://www.npmjs.com).
 
 By default, only the published package will contain the version, which is the only place where it is *really* required, but the updated `package.json` will not be pushed to the Git repository
 
 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.
+
 ## How can I use a npm build script that requires the `package.json`’s version ?
 
 The `package.json`’s version will be updated by the `semantic-release` command just before publishing to [npm](https://www.npmjs.com), therefore it won't be available for scripts ran before the `semantic-release` command.

docs/support/resources.md

@@ -14,6 +14,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)
 
 ## Tutorials
 

docs/usage/ci-configuration.md

@@ -21,12 +21,13 @@ See [CI configuration recipes](../recipes/README.md#ci-configurations) for more
 
 **semantic-release** requires push access to the project Git repository in order to create [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging). The Git authentication can be set with one of the following environment variables:
 
-| Variable                        | Description                                                                                                                                                                                                                  |
-|---------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `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).                                                                                                 |
-| `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. |
+| Variable                                              | Description                                                                                                                                                                                                                  |
+|-------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `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.        |
+| `GIT_CREDENTIALS`                                     | [URL encoded](https://en.wikipedia.org/wiki/Percent-encoding) Git username and password in the format `<username>:<password>`. The username and password must each be individually URL encoded, not the `:` separating them. |
 
 Alternatively the Git authentication can be set up via [SSH keys](../recipes/git-auth-ssh-keys.md).
 

docs/usage/configuration.md

@@ -74,7 +74,7 @@ The branches on which releases should happen. By default **semantic-release** wi
 
 **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.
 
-**Note**: Once **semantic-release** is configured, any user with the permission to push commits on one of those branches will be able to publish a release. It is recommended to protect those branches, for example with [GitHub protected branches](https://help.github.com/articles/about-protected-branches).
+**Note**: Once **semantic-release** is configured, any user with the permission to push commits on one of those branches will be able to publish a release. It is recommended to protect those branches, for example with [GitHub protected branches](https://docs.github.com/github/administering-a-repository/about-protected-branches).
 
 See [Workflow configuration](workflow-configuration.md#workflow-configuration) for more details.
 
@@ -116,7 +116,9 @@ Type: `Boolean`<br>
 Default: `false` if running in a CI environment, `true` otherwise<br>
 CLI arguments: `-d`, `--dry-run`
 
-Dry-run mode, skip publishing, print next version and release notes.
+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.
+
+**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.
 
 ### ci
 

docs/usage/getting-started.md

@@ -10,10 +10,8 @@ In order to use **semantic-release** you must follow these steps:
 Alternatively those steps can be easily done with the [**semantic-release** interactive CLI](https://github.com/semantic-release/cli):
 
 ```bash
-npm install -g semantic-release-cli
-
 cd your-module
-semantic-release-cli setup
+npx semantic-release-cli setup
 ```
 
 ![dialogue](../../media/semantic-release-cli.png)

docs/usage/workflow-configuration.md

@@ -140,7 +140,7 @@ A maintenance branch is characterized by a range which defines the versions that
 
 Maintenance branches are always considered lower than [release branches](#release-branches) and similarly to them, when a commit that would create a version conflict is pushed, **semantic-release** will not perform the release and will throw an `EINVALIDNEXTVERSION` error, listing the problematic commits and the valid branches on which to move them.
 
-**semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release or maintenance branch to another maintenance branch](#merging-into-a-maintenance-branch), however only version version within the branch `range` can be merged. Ia merged version is outside the maintenance branch `range` **semantic-release** will not add to the corresponding channel and will throw an `EINVALIDMAINTENANCEMERGE` error.
+**semantic-release** will automatically add releases to the corresponding distribution channel when code is [merged from a release or maintenance branch to another maintenance branch](#merging-into-a-maintenance-branch), however only versions within the branch `range` can be merged. If a merged version is outside the maintenance branch `range`, **semantic-release** will not add to the corresponding channel and will throw an `EINVALIDMAINTENANCEMERGE` error.
 
 See [publishing maintenance releases recipe](../recipes/maintenance-releases.md) for a detailed example.
 

index.js

@@ -26,7 +26,8 @@ marked.setOptions({renderer: new TerminalRenderer()});
 /* eslint complexity: off */
 async function run(context, plugins) {
   const {cwd, env, options, logger} = context;
-  const {isCi, branch: ciBranch, isPr} = context.envCi;
+  const {isCi, branch, prBranch, isPr} = context.envCi;
+  const ciBranch = isPr ? prBranch : branch;
 
   if (!isCi && !options.dryRun && !options.noCi) {
     logger.warn('This run was not triggered in a known CI environment, running in dry-run mode.');

lib/get-git-auth-url.js

@@ -2,6 +2,7 @@ const {parse, format} = require('url'); // eslint-disable-line node/no-deprecate
 const {isNil} = require('lodash');
 const hostedGitInfo = require('hosted-git-info');
 const {verifyAuth} = require('./git');
+const debug = require('debug')('semantic-release:get-git-auth-url');
 
 /**
  * Determine the the git repository URL to use to push, either:
@@ -25,6 +26,8 @@ module.exports = async ({cwd, env, branch, options: {repositoryUrl}}) => {
     GITLAB_TOKEN: 'gitlab-ci-token:',
     BB_TOKEN: 'x-token-auth:',
     BITBUCKET_TOKEN: 'x-token-auth:',
+    BB_TOKEN_BASIC_AUTH: '',
+    BITBUCKET_TOKEN_BASIC_AUTH: '',
   };
 
   const info = hostedGitInfo.fromUrl(repositoryUrl, {noGitPlus: true});
@@ -40,8 +43,11 @@ module.exports = async ({cwd, env, branch, options: {repositoryUrl}}) => {
 
   // Test if push is allowed without transforming the URL (e.g. is ssh keys are set up)
   try {
+    debug('Verifying ssh auth by attempting to push to  %s', repositoryUrl);
     await verifyAuth(repositoryUrl, branch.name, {cwd, env});
   } catch (_) {
+    debug('SSH key auth failed, falling back to https.');
+
     const envVar = Object.keys(GIT_TOKENS).find((envVar) => !isNil(env[envVar]));
     const gitCredentials = `${GIT_TOKENS[envVar] || ''}${env[envVar] || ''}`;
 

lib/hide-sensitive.js

@@ -2,9 +2,14 @@ const {escapeRegExp, size, isString} = require('lodash');
 const {SECRET_REPLACEMENT, SECRET_MIN_SIZE} = require('./definitions/constants');
 
 module.exports = (env) => {
-  const toReplace = Object.keys(env).filter(
-    (envVar) => /token|password|credential|secret|private/i.test(envVar) && size(env[envVar].trim()) >= SECRET_MIN_SIZE
-  );
+  const toReplace = Object.keys(env).filter((envVar) => {
+    // https://github.com/semantic-release/semantic-release/issues/1558
+    if (envVar === 'GOPRIVATE') {
+      return false;
+    }
+
+    return /token|password|credential|secret|private/i.test(envVar) && size(env[envVar].trim()) >= SECRET_MIN_SIZE;
+  });
 
   const regexp = new RegExp(toReplace.map((envVar) => escapeRegExp(env[envVar])).join('|'), 'g');
   return (output) =>

lib/utils.js

@@ -31,11 +31,14 @@ function isMaintenanceRange(range) {
 }
 
 function getUpperBound(range) {
-  return semver.valid(range)
+  const result = semver.valid(range)
     ? range
-    : ((semver.validRange(range) || '').match(/<(?<upperBound>\d+\.\d+\.\d+-\d+)$/) || [])[1]
-        // https://github.com/npm/node-semver/issues/322
-        .replace(/-\d+$/, '');
+    : ((semver.validRange(range) || '').match(/<(?<upperBound>\d+\.\d+\.\d+(-\d+)?)$/) || [])[1];
+
+  return result
+    ? // https://github.com/npm/node-semver/issues/322
+      result.replace(/-\d+$/, '')
+    : result;
 }
 
 function getLowerBound(range) {

package.json

@@ -37,7 +37,7 @@
     "hook-std": "^2.0.0",
     "hosted-git-info": "^3.0.0",
     "lodash": "^4.17.15",
-    "marked": "^0.8.0",
+    "marked": "^1.0.0",
     "marked-terminal": "^4.0.0",
     "micromatch": "^4.0.2",
     "p-each-series": "^2.1.0",
@@ -57,7 +57,7 @@
     "dockerode": "^3.0.0",
     "file-url": "^3.0.0",
     "fs-extra": "^9.0.0",
-    "got": "^10.5.2",
+    "got": "^11.0.0",
     "js-yaml": "^3.10.0",
     "mockserver-client": "^5.1.1",
     "nock": "^12.0.0",

test/get-git-auth-url.test.js

@@ -299,6 +299,34 @@ test('Return the "https" formatted URL if "gitCredentials" is defined with "BITB
   );
 });
 
+test('Return the "https" formatted URL if "gitCredentials" is defined with "BB_TOKEN_BASIC_AUTH"', async (t) => {
+  const {cwd} = await gitRepo();
+
+  t.is(
+    await getAuthUrl({
+      cwd,
+      env: {...env, BB_TOKEN_BASIC_AUTH: 'username:token'},
+      branch: {name: 'master'},
+      options: {repositoryUrl: 'git@host.null:owner/repo.git'},
+    }),
+    'https://username:token@host.null/owner/repo.git'
+  );
+});
+
+test('Return the "https" formatted URL if "gitCredentials" is defined with "BITBUCKET_TOKEN_BASIC_AUTH"', async (t) => {
+  const {cwd} = await gitRepo();
+
+  t.is(
+    await getAuthUrl({
+      cwd,
+      env: {...env, BITBUCKET_TOKEN_BASIC_AUTH: 'username:token'},
+      branch: {name: 'master'},
+      options: {repositoryUrl: 'git@host.null:owner/repo.git'},
+    }),
+    'https://username:token@host.null/owner/repo.git'
+  );
+});
+
 test('Return the "https" formatted URL if "GITHUB_ACTION" is set', async (t) => {
   const {cwd} = await gitRepo();
 

test/hide-sensitive.test.js

@@ -19,6 +19,11 @@ test('Replace multiple occurences of sensitive environment variable values', (t)
   );
 });
 
+test('Replace sensitive environment variable matching specific regex for "private"', (t) => {
+  const env = {privateKey: 'secret', GOPRIVATE: 'host.com'};
+  t.is(hideSensitive(env)(`https://host.com?token=${env.privateKey}`), `https://host.com?token=${SECRET_REPLACEMENT}`);
+});
+
 test('Escape regexp special characters', (t) => {
   const env = {SOME_CREDENTIALS: 'p$^{.+}\\w[a-z]o.*rd'};
   t.is(
@@ -47,6 +52,11 @@ test('Exclude empty environment variables from the regexp if there is only empty
   t.is(hideSensitive({SOME_PASSWORD: '', SOME_TOKEN: ' \n '})(`https://host.com?token=`), 'https://host.com?token=');
 });
 
+test('Exclude nonsensitive GOPRIVATE environment variable for Golang projects from the regexp', (t) => {
+  const env = {GOPRIVATE: 'host.com'};
+  t.is(hideSensitive(env)(`https://host.com?token=`), 'https://host.com?token=');
+});
+
 test('Exclude environment variables with value shorter than SECRET_MIN_SIZE from the regexp', (t) => {
   const SHORT_TOKEN = repeat('a', SECRET_MIN_SIZE - 1);
   const LONG_TOKEN = repeat('b', SECRET_MIN_SIZE);

test/index.test.js

@@ -1258,7 +1258,7 @@ test('Allow local releases with "noCi" option', async (t) => {
 
   const semanticRelease = requireNoCache('..', {
     './lib/get-logger': () => t.context.logger,
-    'env-ci': () => ({isCi: false, branch: 'master', isPr: true}),
+    'env-ci': () => ({isCi: false, branch: 'master', isPr: false}),
   });
   t.truthy(
     await semanticRelease(options, {
@@ -1357,7 +1357,7 @@ test('Returns false if triggered by a PR', async (t) => {
 
   const semanticRelease = requireNoCache('..', {
     './lib/get-logger': () => t.context.logger,
-    'env-ci': () => ({isCi: true, branch: 'master', isPr: true}),
+    'env-ci': () => ({isCi: true, branch: 'master', prBranch: 'patch-1', isPr: true}),
   });
 
   t.false(

test/utils.test.js

@@ -71,17 +71,17 @@ test('isMaintenanceRange', (t) => {
 
 test('getUpperBound', (t) => {
   t.is(getUpperBound('1.x.x'), '2.0.0');
-  // T.is(getUpperBound('1.X.X'), '2.0.0');
-  // t.is(getUpperBound('10.x.x'), '11.0.0');
-  // t.is(getUpperBound('1.x'), '2.0.0');
-  // t.is(getUpperBound('10.x'), '11.0.0');
-  // t.is(getUpperBound('1.0.x'), '1.1.0');
-  // t.is(getUpperBound('10.0.x'), '10.1.0');
-  // t.is(getUpperBound('10.10.x'), '10.11.0');
-  // t.is(getUpperBound('1.0.0'), '1.0.0');
-  // t.is(getUpperBound('10.0.0'), '10.0.0');
+  t.is(getUpperBound('1.X.X'), '2.0.0');
+  t.is(getUpperBound('10.x.x'), '11.0.0');
+  t.is(getUpperBound('1.x'), '2.0.0');
+  t.is(getUpperBound('10.x'), '11.0.0');
+  t.is(getUpperBound('1.0.x'), '1.1.0');
+  t.is(getUpperBound('10.0.x'), '10.1.0');
+  t.is(getUpperBound('10.10.x'), '10.11.0');
+  t.is(getUpperBound('1.0.0'), '1.0.0');
+  t.is(getUpperBound('10.0.0'), '10.0.0');
 
-  // t.is(getUpperBound('foo'), undefined);
+  t.is(getUpperBound('foo'), undefined);
 });
 
 test('getLowerBound', (t) => {