Feature request: Add a parameter to disable the check for an upstream branch

[adrianschmidt]

New feature motivation

I cannot dry-run the release from a branch that has no upstream.

This is a problem for us, because we use Jenkins to automatically merge the new branch and the target branch into a temporary branch only existing on the build agent, and run our CI pipeline on that. That way, we know that if the build is green there, it will be green when merged to master. So far, we've been running semantic-release in dry-run mode on these PR-branches, to make sure that part of the process also work correctly. With this change, we can no longer do that.

I think it should be possible (in some way) to dry-run a release on a branch with no upstream.

New feature description

I absolutely agree with #1168 (comment) that we don't want the dry-run to pass in a situation where the "live" run would fail. But, just like it's possible to change the branches config or disable the CI-check, it ought to be possible to disable the requirement on an upstream branch.

So, I suggest adding a parameter to disable this. --verify-upstream-branch / --no-verify-upstream-branch maybe? I'm not good at coming up with short descriptions… 😄

New feature implementation

I haven't looked into it, so no idea at the moment. I might be able to look into it (and maybe supply a PR, depending on how difficult it would be) if the idea itself is approved.

Environment

Since I started this out as a bug report, I might as well post the stuff I collected about my env…

Hidden for brevity, click to expand!

• semantic-release version: 17.0.4 (introduced in 16.0.0)
• CI environment: Jenkins
• Plugins used:

  '@semantic-release/commit-analyzer',
  '@semantic-release/release-notes-generator',
  '@semantic-release/changelog',
  '@semantic-release/npm',
  '@semantic-release/git',
  '@semantic-release/github',
  '@semantic-release/exec',
  

• semantic-release configuration:

  module.exports = {
      branches: [
          "+([0-9])?(.{+([0-9]),x}).x",
          "master",
          {name: "beta", prerelease: true},
          {name: "staging", prerelease: true},
          "my-feature", // temporary for this test case, to avoid the branch-config being a problem
      ],
      plugins: [
          '@semantic-release/commit-analyzer',
          '@semantic-release/release-notes-generator',
          '@semantic-release/changelog',
          '@semantic-release/npm',
          '@semantic-release/git',
          '@semantic-release/github',
          [
              '@semantic-release/exec',
              {
                  publishCmd:
                      'npm run docz:publish -- --v=${nextRelease.version} --dryRun=${options.dryRun}', // exec doesn't run in dry-run mode, which is understandable, but also annoying
              },
          ],
      ],
      npmPublish: true,
  };

• CI logs:

  ╭ 09:37:05 ~/src/lime-elements [semantic-test]
  ╰ $ npx semantic-release -d
  [9:44:45 AM] [semantic-release] › ℹ  Running semantic-release version 17.0.4
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/changelog"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/npm"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/git"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/github"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "verifyConditions" from "@semantic-release/exec"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/commit-analyzer"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "analyzeCommits" from "@semantic-release/exec"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "verifyRelease" from "@semantic-release/exec"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/release-notes-generator"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "generateNotes" from "@semantic-release/exec"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/changelog"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/npm"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/git"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "prepare" from "@semantic-release/exec"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/npm"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/github"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "publish" from "@semantic-release/exec"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/npm"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/github"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "addChannel" from "@semantic-release/exec"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "success" from "@semantic-release/github"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "success" from "@semantic-release/exec"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "fail" from "@semantic-release/github"
  [9:44:46 AM] [semantic-release] › ✔  Loaded plugin "fail" from "@semantic-release/exec"
  [9:44:52 AM] [semantic-release] › ℹ  This test run was triggered on the branch semantic-test, while semantic-release is configured to only publish from master, therefore a new version won’t be published.

PS: LOVE semantic-release ❤️❤️❤️

[pvdlg]

This is a problem for us, because we use Jenkins to automatically merge the new branch and the target branch into a temporary branch only existing on the build agent, and run our CI pipeline on that. That way, we know that if the build is green there, it will be green when merged to master. So far, we've been running semantic-release in dry-run mode on these PR-branches, to make sure that part of the process also work correctly. With this change, we can no longer do that.

What you describe is what most modern CI do automatically. In such cases the CI provide environment variables that are detected by semantic-release, so we can skip the run:

semantic-release/index.js

Line 48 in da5d06c

logger.log("This run was triggered by a pull request and therefore a new version won't be published.");

I would recommend to move away from Jenkins and use a modern CI where all that will be handled for you out of the box. If you can't you should try to find a way to skip semantic-release by yourself on those "virtual" branches.

[adrianschmidt]

This is a problem for us, because we use Jenkins to automatically merge the new branch and the target branch into a temporary branch only existing on the build agent, and run our CI pipeline on that. That way, we know that if the build is green there, it will be green when merged to master. So far, we've been running semantic-release in dry-run mode on these PR-branches, to make sure that part of the process also work correctly. With this change, we can no longer do that.

What you describe is what most modern CI do automatically. In such cases the CI provide environment variables that are detected by semantic-release, so we can skip the run:

semantic-release/index.js

Line 48 in da5d06c

logger.log("This run was triggered by a pull request and therefore a new version won't be published.");

I would recommend to move away from Jenkins and use a modern CI where all that will be handled for you out of the box. If you can't you should try to find a way to skip semantic-release by yourself on those "virtual" branches.

I think you misunderstood me. By default, the semantic-release run is skipped, just like you intend. So that part is working. It's just that we don't want to entirely skip the semantic-release run, we want to do a dry-run. To do this, we set the dry-run parameter, and we explicitly set the branches parameter to accept the branch we're on. As expected, that makes semantic-release do a dry-run.

My problem now is that the dry-run fails because there is no identical branch on origin. Which, again, is per-design, as a "live" run would fail for that as well. What I'm asking for is a parameter to make semantic-release ignore the check for an identical branch on origin.

In other words, the scenario I have is: "I know this branch is local only, but I also happen to know this branch looks identical to what master will look like once this is merged, so I would like to know if this branch passes a dry-run where the check for origin is explicitly skipped. I'm aware of the caveats and take full responsibility." 🙂

Edit: we are actually moving away from Jenkins towards GitHub Actions, and as far as I know GitHub Actions doesn't provide any way to run tests on this type of virtual branches where the current branch and the target branch has been merged, so we will probably soon lose the option to do this anyway, at least for now. I still think my use case is reasonable, and it would surprise me if no one else wants to do the same thing…? Or am I missing something, and there's some other way we should be using semantic-release?

I guess it should also be said that we are on an "always release" scheme, so for every merge to master, we do a live semantic-release run. That's why we want to do the dry-run before we merge, because once we merge it's too late anyway.

[pvdlg]

I think you misunderstood me. By default, the semantic-release run is skipped, just like you intend. So that part is working. It's just that we don't want to entirely skip the semantic-release run, we want to do a dry-run. To do this, we set the dry-run parameter, and we explicitly set the branches parameter to accept the branch we're on. As expected, that makes semantic-release do a dry-run.

That is not supported. If we were to support generating the "hypothetical" changelog on PR we would do it with a GitHub app (see #974) not with --dry-run.

[adrianschmidt]

Ok. I understand.