Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
effektsvk opened this issue Nov 25, 2024 · 4 comments · May be fixed by cycjimmy/semantic-release-action#225
Open

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

effektsvk opened this issue Nov 25, 2024 · 4 comments · May be fixed by cycjimmy/semantic-release-action#225

Comments

@effektsvk
Copy link

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
@davidspek davidspek linked a pull request Dec 30, 2024 that will close this issue
Open
5 tasks
@babblebey
Copy link
Member

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:

@effektsvk
Copy link
Author

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
Copy link
Member

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
Copy link
Author

effektsvk commented Jan 17, 2025 •
edited
Loading

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: add ability to unset GITHUB_ACTION env var davidspek/semantic-release-action
2 participants
@effektsvk @babblebey