Add a flag or some setting that ignores the logic for CI

[effektsvk]

New feature motivation

We would like to run a dry run release on PRs (specifically Renovate PRs), so that when some dependency update breaks the release we can see it before it's merged.

From what I've gathered, the flow is something like this:

1. semantic-release detects whether it's running in CI using env-ci package with detect functions
2. in our case it's GitHub Actions, so it will use env-ci/services/github.js for parsing the branch name, but this results in the branch name: refs/pull/PR_NUMBER/merge
3. in semantic-release there is getBranches function which fetches all branches but since refs/pull/PR_NUMBER/merge is not a normal branch, it doesn't count it, even if I add it to branches in .releaserc.js
   

   semantic-release/index.js

   Line 68 in 656a1a4

   context.branches = await getBranches(options.repositoryUrl, ciBranch, context);

I found a workaround that if I unset GITHUB_ACTIONS env variable, it works as we need it. It only makes the detect function in env-ci package think that it's running locally.
https://github.com/semantic-release/env-ci/blob/14ca551218ab5c0ad5bddb14ab0bc154c8be727f/services/github.js#L36-L38

Maybe the issue is more related to env-ci package than semantic-release itself, but I need semantic-release to behave in a certain way so I created the issue here. I can move if necessary.

P.S. It also might be slightly related to this issue: #3278

New feature description

I'm not sure what is the best way to solve this, whether it's some kind of flag/setting I can pass to semantic-release or maybe an environment variable so that env-ci has access to it and semantic-release can remain untouched. Maybe you can come up with a different solution.

New feature implementation

No response

[babblebey]

Hi @effektsvk,

How are you currently running these "dry run release on PRs (specifically Renovate PRs)"!? I'd assume its through GitHub Actions!? i.e. you are running semantic-release directly from the cli within the actions that runs on these PRs!?

Are you leveraging the --no-ci and --branches flags??

Note:

• The --no-ci flag help you skips the ci verification, this infers the assumption that you are running a release from local environment and allows it - https://semantic-release.gitbook.io/semantic-release/usage/configuration#ci
• The --branches flag allows you to override the current release branch set in your config .releaserc file, allowing you to dynamically set the current PR branch as your release branching, hence mocking the scenario you require - https://semantic-release.gitbook.io/semantic-release/usage/configuration#branches

[effektsvk]

Hi,

Yes, it is GitHub Actions running on GitHub PRs. We run semantic-release with run inside a custom GitHub workflow.

We're also using a custom config which sets the branches, instead of using the --branches flag. (IIRC I also tried --branches flag when debugging)

Using the --no-ci flag didn't help. I don't remember the exact behavior, I can set up the environment again and test if you need that information, but --no-ci only helped me when running locally on my computer.

[babblebey]

I can set up the environment again and test if you need that information, but --no-ci only helped me when running locally on my computer.

Please do, and make it public too

[effektsvk]

Hi @babblebey,

I finished the reproduction, I made 5 versions of workflows, all of them have --dry-run:

1. the workaround version, it does 2 things:
   i. sets branches in config to the name of branch of current PR
   ii. sets GITHUB_ACTIONS=""
2. --no-ci flag
3. --no-ci flag and --branches
4. omitted --no-ci (ci: true)
5. omitted --no-ci (ci: true) and --branches

Both workflows with --no-ci (2, 3) print this:
[4:33:08 PM] [semantic-release] › ℹ This run was triggered by a pull request and therefore a new version won't be published.

Both workflows with ci: true (4, 5) print this:
[4:33:05 PM] [semantic-release] › ℹ This test run was triggered on the branch refs/pull/2/merge, while semantic-release is configured to only publish from esl/test2, therefore a new version won’t be published.

Here is the link for the PR with the results:
erik-slovak/semantic-release-issue-3518#2

edit: the repo is on my work account, that's why the username is different