WIP set extendEnv: false execa option

That results in the value `"null"` instead of undefined

.github/workflows/release.yml

@@ -13,7 +13,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
-      - uses: actions/setup-node@v2
+      - uses: actions/setup-node@v1
       - uses: bahmutov/npm-install@v1
       - run: npx semantic-release
         env:

.github/workflows/test.yml

@@ -4,8 +4,8 @@ on:
   push:
     branches:
       - master
-      # renovate/** branches are generated by https://github.com/apps/renovate
       - renovate/**
+      - 1692/setup-renovate-debug
 
   pull_request:
     types:
@@ -17,9 +17,9 @@ jobs:
     strategy:
       matrix:
         node-version:
-          - 10.18.0
+          # - 10
           - 12
-          - 14
+          # - 14
 
     runs-on: ubuntu-latest
 
@@ -28,13 +28,11 @@ jobs:
       - 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@v1
         with:
           node-version: ${{ matrix.node-version }}
-      - name: Ensure dependencies are compatible with the version of node
-        run: echo 'engine-strict=true' >> .npmrc
       - uses: bahmutov/npm-install@v1
-      - run: npm run test:ci
+      - run: npx ava test/integration.test.js
 
   # separate job to set as required in branch protection,
   # as the build names above change each time Node versions change
@@ -43,6 +41,6 @@ jobs:
     needs: test_matrix
     steps:
       - uses: actions/checkout@v2
-      - uses: actions/setup-node@v2
+      - uses: actions/setup-node@v1
       - uses: bahmutov/npm-install@v1
       - run: npm run lint

README.md

@@ -1,8 +1,8 @@
 <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://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 href="https://spectrum.chat/semantic-release">
+    <img alt="Join the community on Spectrum" src="https://withspectrum.github.io/badge/badge.svg">
   </a>
   <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">
@@ -48,7 +48,7 @@ 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/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.
+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.
 
 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.
 
@@ -131,7 +131,7 @@ In order to use **semantic-release** you need:
 ## Get help
 
 - [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release)
-- [GitHub Discussions](https://github.com/semantic-release/semantic-release/discussions)
+- [Spectrum community](https://spectrum.chat/semantic-release)
 - [Twitter](https://twitter.com/SemanticRelease)
 
 ## Badge

bin/semantic-release.js

@@ -21,6 +21,13 @@ See https://github.com/semantic-release/semantic-release/blob/master/docs/suppor
   process.exit(1);
 }
 
+console.log("DEBUG START ==========")
+console.log('process.env')
+console.log(process.env)
+console.log('envCi({ env: process.env })')
+console.log(require('env-ci')({ env: process.env }))
+console.log("DEBUG END ==========")
+
 execa('git', ['--version'])
   .then(({stdout}) => {
     var gitVersion = findVersions(stdout)[0];

docs/README.md

@@ -1,7 +1,7 @@
 # semantic-release documentation
 
 - [Usage](usage/README.md) - **semantic-release** installation and configuration
-- [Extending](extending/README.md) - Extending **semantic-release** with plugins and shareable configurations
+- [Extending](extending/README.md)- Extending **semantic-release** with plugins and shareable configurations
 - [Recipes](recipes/README.md) - Community written recipes for common **semantic-release** use-cases
 - [Developer Guide](developer-guide/README.md) - The essentials of writing a **semantic-release** plugin or shareable configurations
 - [Support](support/README.md) - FAQ and troubleshooting

docs/developer-guide/plugin.md

@@ -1,18 +1,14 @@
 # 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 `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:
+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:
 
-- `verifyConditions`
-- `analyzeCommits`
-- `verifyRelease`
-- `generateNotes`
-- `addChannel`
+- `verify`
 - `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 `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 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.
 
 In addition to the lifecycle methods, each lifecyle is passed two objects:
 
@@ -97,131 +93,7 @@ if (message.length) {
 }
 ```
 
-## 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`
-  * Similar object as `lastRelease` (see above)
-
-#### 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
+## 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:
 
@@ -229,6 +101,6 @@ Similar to `options`, environment variables exist to allow users to pass tokens
 const { env } = context;
 
 if (env.GITHUB_TOKEN) {
-  //...
+    //...
 }
-```
+```

docs/extending/plugins-list.md

@@ -20,7 +20,7 @@
   - `publish`: Publish the package on the npm registry
 - [@semantic-release/gitlab](https://github.com/semantic-release/gitlab)
   - `verifyConditions`: Verify the presence and the validity of the GitLab authentication and release configuration
-  - `publish`: Publish a [GitLab release](https://docs.gitlab.com/ee/user/project/releases/)
+  - `publish`: Publish a [GitLab release](https://docs.gitlab.com/ce/workflow/releases.html)
 - [@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
@@ -91,9 +91,6 @@
 - [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.

docs/recipes/distribution-channels.md

@@ -97,7 +97,7 @@ The Git history of the repository is now:
 
 After a period of feedback from our users using the `@next` dist-tag we feel confident to make our big feature available to all users. To do so we merge the `next` branch into `master`. There should be no conflict as `next` is strictly ahead of `master`.
 
-Once the merge commit is pushed to `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`.
+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`.
 
 The Git history of the repository is now:
 

docs/recipes/github-actions.md

@@ -25,7 +25,7 @@ on:
 jobs:
   release:
     name: Release
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-18.04
     steps:
       - name: Checkout
         uses: actions/checkout@v2

docs/support/resources.md

@@ -15,7 +15,6 @@
 - ["Introduction to SemVer" - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2)
 - ["Introduction to Semantic Release" - liv](https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8)
 - ["Series - Semantic Release Automation" - Abdelrahman Wahdan](https://dev.to/abdelrahmanahmed/semantic-release-and-how-to-automate-it-part-1-4pa2)
-- ["Explain semantic release and how to use it on GitLab pipeline"](https://regoo707.medium.com/auto-bump-apps-versions-and-releases-using-gitlab-pipeline-e32f1d7fa3ee)
 
 ## Tutorials
 

docs/support/troubleshooting.md

@@ -65,5 +65,5 @@ To recover from that situation, do the following:
 
 1. Delete the tag(s) for the release(s) that have been lost from the git history. You can delete each tag from remote using `git push origin :[TAG NAME]`, e.g. `git push origin :v2.0.0-beta.1`. You can delete tags locally using `git tag -d [TAG NAME]`, e.g. `git tag -d v2.0.0-beta.1`.
 2. Re-create the tags locally: `git tag [TAG NAME] [COMMIT HASH]`, where `[COMMIT HASH]` is the new commit that created the release for the lost tag. E.g. `git tag v2.0.0-beta.1 abcdef0`
-3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' 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"]}'
+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"]}'
 4. Push the local notes: `git push --force origin refs/notes/semantic-release`. The `--force` is needed after the rebase. Be careful.

docs/usage/ci-configuration.md

@@ -8,7 +8,7 @@ Here is a few example of the CI services that can be used to achieve this:
 - [CircleCI Workflows](https://circleci.com/docs/2.0/workflows)
 - [GitHub Actions](https://github.com/features/actions)
 - [Codeship Deployment Pipelines](https://documentation.codeship.com/basic/builds-and-configuration/deployment-pipelines)
-- [GitLab Pipelines](https://docs.gitlab.com/ce/ci/introduction/)
+- [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html#introduction-to-pipelines-and-jobs)
 - [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).

lib/get-config.js

@@ -9,10 +9,19 @@ 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).search(cwd)) || {};
+  const {config, filepath} = (await cosmiconfig(CONFIG_NAME, {searchPlaces: CONFIG_FILES}).search(cwd)) || {};
 
   debug('load config from: %s', filepath);
 

lib/git.js

@@ -318,7 +318,7 @@ async function getNote(ref, execaOptions) {
 }
 
 /**
- * Add JSON note to a given reference.
+ * Get and parse the JSON note of a given reference.
  *
  * @param {Object} note The object to save in the reference note.
  * @param {String} ref The Git reference to add the note to.

package.json

@@ -26,19 +26,19 @@
     "@semantic-release/npm": "^7.0.0",
     "@semantic-release/release-notes-generator": "^9.0.0",
     "aggregate-error": "^3.0.0",
-    "cosmiconfig": "^7.0.0",
+    "cosmiconfig": "^6.0.0",
     "debug": "^4.0.0",
     "env-ci": "^5.0.0",
-    "execa": "^5.0.0",
+    "execa": "^4.0.0",
     "figures": "^3.0.0",
     "find-versions": "^4.0.0",
-    "get-stream": "^6.0.0",
+    "get-stream": "^5.0.0",
     "git-log-parser": "^1.2.0",
     "hook-std": "^2.0.0",
-    "hosted-git-info": "^4.0.0",
-    "lodash": "^4.17.21",
-    "marked": "^2.0.0",
-    "marked-terminal": "^4.1.1",
+    "hosted-git-info": "^3.0.0",
+    "lodash": "^4.17.15",
+    "marked": "^1.0.0",
+    "marked-terminal": "^4.0.0",
     "micromatch": "^4.0.2",
     "p-each-series": "^2.1.0",
     "p-reduce": "^2.0.0",
@@ -50,24 +50,24 @@
     "yargs": "^16.2.0"
   },
   "devDependencies": {
-    "ava": "3.15.0",
-    "clear-module": "4.1.1",
-    "codecov": "3.8.1",
-    "delay": "5.0.0",
-    "dockerode": "3.2.1",
-    "file-url": "3.0.0",
-    "fs-extra": "9.1.0",
-    "got": "11.8.2",
-    "js-yaml": "3.14.1",
-    "mockserver-client": "5.11.2",
-    "nock": "13.0.11",
-    "nyc": "15.1.0",
-    "p-retry": "4.5.0",
-    "proxyquire": "2.1.3",
-    "sinon": "9.2.4",
-    "stream-buffers": "3.0.2",
-    "tempy": "1.0.0",
-    "xo": "0.29.1"
+    "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"
   },
   "engines": {
     "node": ">=10.18"

test/get-config.test.js

@@ -191,28 +191,6 @@ 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();
@@ -235,28 +213,6 @@ test('Read options from release.config.js', async (t) => {
   t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
 });
 
-test('Read options from release.config.cjs', async (t) => {
-  // Create a git repository, set the current working directory at the root of the repo
-  const {cwd} = await gitRepo();
-  const options = {
-    analyzeCommits: {path: 'analyzeCommits', param: 'analyzeCommits_param'},
-    branches: ['test_branch'],
-    repositoryUrl: 'https://host.null/owner/module.git',
-    tagFormat: `v\${version}`,
-    plugins: false,
-  };
-  // Create release.config.cjs in repository root
-  await writeFile(path.resolve(cwd, 'release.config.cjs'), `module.exports = ${JSON.stringify(options)}`);
-
-  const {options: result} = await t.context.getConfig({cwd});
-
-  const expected = {...options, branches: ['test_branch']};
-  // Verify the options contains the plugin config from release.config.cjs
-  t.deepEqual(result, expected);
-  // Verify the plugins module is called with the plugin options from release.config.cjs
-  t.deepEqual(t.context.plugins.args[0][0], {options: expected, cwd});
-});
-
 test('Prioritise CLI/API parameters over file configuration and git repo', async (t) => {
   // Create a git repository, set the current working directory at the root of the repo
   let {cwd, repositoryUrl} = await gitRepo();

test/helpers/gitbox.js

@@ -63,7 +63,7 @@ async function createRepo(name, branch = 'master', description = `Repository ${n
   const authUrl = `http://${gitCredential}@${SERVER_HOST}:${HOST_PORT}/git/${name}.git`;
 
   // Retry as the server might take a few ms to make the repo available push
-  await pRetry(() => initBareRepo(authUrl, branch), {retries: 5, minTimeout: 500, factor: 2});
+  await pRetry(() => initBareRepo(authUrl, branch), {retries: 3, minTimeout: 500, factor: 2});
   const cwd = await gitShallowClone(authUrl);
 
   return {cwd, repositoryUrl, authUrl};

test/integration.test.js

@@ -1,5 +1,5 @@
 const path = require('path');
-const test = require('ava');
+const { serial: test } = require('ava');
 const proxyquire = require('proxyquire');
 const {escapeRegExp} = require('lodash');
 const {writeJson, readJson} = require('fs-extra');
@@ -29,7 +29,11 @@ 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 {
+  GITHUB_ACTION,
+  GITHUB_TOKEN,
+  ...processEnvWithoutGitHubActionsVariables
+} = process.env
 const env = {
   ...processEnvWithoutGitHubActionsVariables,
   ...npmRegistry.authEnv,
@@ -652,12 +656,7 @@ 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,
-    extendEnv: 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)}`));