Add option to skip token verification (or entire plugin) for dry runs

[BinToss]

Related

• Fails with missing GitHub token when --dry-run and --no-ci #261 (comment)
• conventional-changelog-conventionalcommits v8.0.0 breaks semantic release release-notes-generator#633 (comment)

Sure, if we already have a token set up and securely saved somewhere, we can always npx cross-env GITHUB_TOKEN=gh_pat*** npx semantic-release --dry-run, but sometimes we just can't be bothered to go through the steps of decrypting and copying the token value from secure storage. Or perhaps we don't care about token validation, but still want to dry run all other 'verify conditions'.

potential solutions (requires changes in @semantic-release/semantic-release)
--no-github? Skip the entire github plugin.
--no-token? Its implementation in semantic-release's CLI may affect plugins such as @semantic-release/npm.
--no-token=@semantic-release/github,@semantic-release/gitlab,@semantic-release/npm? Pass comma-separated plugin names to indicate which plugins' token verification should be skipped?

It may be feasible to introduce a startsWith('!') pattern to remove specific plugins from the options.plugins before the plugins are passed to and loaded by @semantic-release/semantic-release/lib/plugins/index.js#default.
https://github.com/semantic-release/semantic-release/blob/5f05152fe642f29dda437ce78e1ce3bcb89f1dea/lib/get-config.js#L63-L92

+ // if any PluginSpec is a string and starts with '!', remove all instances of the negated plugins from the array.
+ /** @type { string[] } */
+ const negatedPlugins = options.plugins.filter(v => v[0] === '!');
+
+ options.plugins = options.plugins.filter(
+     // keep plugins whose IDs do not startWith '!'
+     plugin => !(negatedPlugins.includes(plugin))
+ ).filter(
+     // keep plugins that are *not* negated by negatedPlugins
+     plugin => {
+         /** @type { string | [string, Record<keyof any, unknown>] } */
+         const p = plugin;
+         if (typeof p === 'string')
+             return !(negatedPlugins.includes('!' + p));
+         else
+             return !(negatedPlugins.includes('!' + p[0]));
+     }
+ )
+
  if (options.ci === false) {
      options.noCi = true;
  }

  debug("options values: %O", options);

  return { options, plugins: await plugins({ ...context, options }, pluginsPath) };

[babblebey]

Hi @BinToss,

Thank you for the suggestion. While we might look at this inhouse, I think IMO that having such option beats the core objective of the dryRun mode... As stated in the docs below...

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.

This states in the "Note" paragraph that the verification part of the run via the verifyConditions lifecycle is imperative to the operation of the dryRun regardless of the plugins you're consuming for the stated reason.

Suggestion for your use case

If you wish to still be able to do a dryRun without verification of GHToken, then the cleanest path to that would be to do the dryRun without the @semantic-release/github plugin.

🤔 YES, it's a default plugin, you couldn't possibly remove it without having to write a configuration file (in cases where you're doing the default without config). ALSO, you might already have a configuration file and wouldn't possibly want to tamper with it just to do this particular dry run.... SO do this...

Run the cli with your plugin configuration inline using the -p or --plugins flag... see command below

npx semantic-release --dry-run -p "@semantic-release/commit-analyzer", "@semantic-release/release-notes-generator", "@semantic-release/npm"

This will allow you decide the plugins to run with the operation onetime disregarding the config file. Learn more about the --plugins flag at https://semantic-release.gitbook.io/semantic-release/usage/configuration#plugins