Getting the error "The local branch <branch name> is behind the remote one, therefore a new version won't be published" during CI

[hpe-ykoehler]

Hi,

I have many repo using semantic-release tool. In one or two repo in particular, I am starting to see the error mention in the title.

During CI we do not pull branches, we pull git commit hash directly.

So I am confused as to why the semantic-release tool case that a local branch is up-to-date or not with the remote, can't the tool use the remote branch instead of trying to use a local branch?

What is the purpose of this error?

[travi]

in order to support making commits during the release process (even though we recommend avoiding this if you can, we still need to account for it in the core workflow), we need to make sure we are committing to the head of the branch. under normal conditions, this error can mostly be ignored since the next build of that branch (the one triggered by the push that makes the current state behind the remote) will execute semantic-release again and process all of the commits since the previous release.

During CI we do not pull branches, we pull git commit hash directly.

is there a specific reason you are working around the natural behavior? it seems like you would be making things harder on yourself, at least related to semantic-release

[hpe-ykoehler]

ok makes sense, but semantic-release is creating a commit on its own by updating the version no? (or changelog) or is that related to plugins?

[travi]

a commit is only made if you have opted in to the git plugin (which again, we recommend against if you can avoid it)

[hpe-ykoehler]

It is actually the natural way to do CI to checkout git hash and not branch, because the hash make sure you build what is being asked and not something that may have change in between.

Using "devel" may change by the time the CI kicks in, and therefore the build is no longer related to the commit in question.

It works normally, but somehow in this particular case we keep hitting this, and I am mostly trying to find the root cause, not blaming something wrong in the tool.

[travi]

as long as the commit that you are checking out is the latest commit on that branch, you should not hit this problem

[hpe-ykoehler]

Thanks, I may have found the problem from your comment.

So far the only pattern I can suspect is this:

CD start devel = remote/devel
CI start
CI finish/nerge = modifying remote/devel
CD gets to the semantic-release point local devel no more = to remote/devel (which would require semantic-relese to do a git fetch)

that would make sense "if" semantic-release actually fetch the remote again, is that possible?

[travi]

as i mentioned before, the execution triggered by the push that caused the branch to differ between remote and the current ci run will resolve the issue. the "error" isnt really an error and can be safely ignored. it is basically just stating that no release will happen on this run because it will happen on the next one instead.

we have no intention to fetch a different commit in the existing execution since that would result in acting on a different commit than the one that triggered the run, which you highlighted already as undesireable.

[hpe-ykoehler]

I will see if we can "abort" any existing CD job when a CI get merge, and then restarted it to see if this could remove this issue from happening.

[hpe-ykoehler]

We treat this as an error because we expected a new version to be created (not out of this particular CD run but somehow in the same day), and that on our side there appears to be no additional CD triggered. As such, this may be where the problem lies, where we fail to detect the need to get the CD going again.

Will investigate that, thanks for your prompt answers and information, it is appreciated and I think we can close this.

[travi]

but somehow in the same day

you've mentioned a few details that might be causing some additional friction, possibly even to the point where you might be looking for a tool that isnt actually semantic-release. semantic-release acts on commits, not timeframes like "same day". if the commits contain consumer facing changes (determined by the commit convention), a release should be made immediately (unless it can be determined that more changes have happened and they are expected to be reprocessed by the next, immediate execution).

also, you mention a devel branch, which suggests that you might be using gitflow. officially, semantic-release does not support gitflow. instead, we recommend a trunk-based development workflow, like github flow. this encourages merging changes to your primary release branch and releasing from there. while pre-release branches are used by many folks to simulate gitflow, this is not the intended use for our pre-release workflow and we do not provide a workflow for QA'ing changes after releasing a non-stable build.

[hpe-ykoehler]

We actually found what is going on, we use a 2 branch approach, dev works on devel, those are like the "next" version but we actually use
a pre-release such as alpha for devel. The developer also meanwhile trigger a release on mainline, and what happen is that mainline got auto-merge to devel (modifying the remote/devel) but there was no triggered CD build after that event, this is why the expected version never came to life.

User-created PR (CI Start)
CI got merge
devel CD kicked in
A concurrent CI got a merge into mainline
Mainline got auto-merge to devel
The existing CD does not create a new version because a different remove/devel exists (which I think is fine)
Here we would have expected a new CD to kick in on devel because auto-merge did modify devel and that didn't happen, which is the source of the problem.

Now I am not aware of all the CI/CD infra details but I have timestamp/events proving this is what happened at this time, we will fix that and should be good to go again. Our auto-merge is not using a PR system... bypassing stuff and explain why things broked.