Parallel semantic-release jobs interfere with each other

[martinkrulltott]

In team analytics we've noticed that running parallel semantic-release jobs, e.g. by triggering two PRs targeting different branches to merge at the same time, interfere with each other in a way that the jobs fail.
As seen here and here.

A common occurrence of this in our repos is when working with backports, where each PR target a different base. Merging these at simultaneously causes the jobs to fail.

The simplest work-around seems to be to re-run the jobs one by one (i.e. not parallel). As pointed out by @varl here.

As CI logs expire after a while, I've attached a part of the log below for reference:

[7:10:48 AM] [semantic-release] › ✔ Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[7:10:50 AM] [semantic-release] › ✖ An error occurred while running semantic-release: Error: Command failed with exit code 1: git push https://[secure]@github.com/dhis2/analytics.git refs/notes/semantic-release
To https://github.com/dhis2/analytics.git
! [rejected] refs/notes/semantic-release -> refs/notes/semantic-release (fetch first)
error: failed to push some refs to 'https://github.com/dhis2/analytics.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
at makeError (/home/runner/.npm/_npx/1916/lib/node_modules/@dhis2/cli-utils/node_modules/semantic-release/node_modules/execa/lib/error.js:60:11)
at handlePromise (/home/runner/.npm/_npx/1916/lib/node_modules/@dhis2/cli-utils/node_modules/semantic-release/node_modules/execa/index.js:118:26)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async pushNotes (/home/runner/.npm/_npx/1916/lib/node_modules/@dhis2/cli-utils/node_modules/semantic-release/lib/git.js:248:3)
at async run (/home/runner/.npm/_npx/1916/lib/node_modules/@dhis2/cli-utils/node_modules/semantic-release/index.js:194:5)
at async module.exports (/home/runner/.npm/_npx/1916/lib/node_modules/@dhis2/cli-utils/node_modules/semantic-release/index.js:260:22)
at async Object.handler (/home/runner/.npm/_npx/1916/lib/node_modules/@dhis2/cli-utils/src/cmds/release.js:123:24) {
shortMessage: 'Command failed with exit code 1: git push https://[secure]@github.com/dhis2/analytics.git refs/notes/semantic-release',
command: 'git push https://[secure]@github.com/dhis2/analytics.git refs/notes/semantic-release',
escapedCommand: 'git push "https://[secure]@github.com/dhis2/analytics.git" "refs/notes/semantic-release"',
exitCode: 1,
signal: undefined,
signalDescription: undefined,
stdout: '',
stderr: 'To https://github.com/dhis2/analytics.git\n' +
' ! [rejected] refs/notes/semantic-release -> refs/notes/semantic-release (fetch first)\n' +
"error: failed to push some refs to 'https://github.com/dhis2/analytics.git'\n" +
'hint: Updates were rejected because the remote contains work that you do\n' +
'hint: not have locally. This is usually caused by another repository pushing\n' +
'hint: to the same ref. You may want to first integrate the remote changes\n' +
"hint: (e.g., 'git pull ...') before pushing again.\n" +
"hint: See the 'Note about fast-forwards' in 'git push --help' for details.",
failed: true,
timedOut: false,
isCanceled: false,
killed: false
}

[ghost]

@martinkrulltott @amcgee We should be able to use github's new concurrency setting to coordinate releases that need to happen sequentially. I've been using this myself to only run the latest task (cancelling any previous ones), but you could also use this without cancel-in-progress and just force it to wait for a previous task to complete on release branches.

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency

It's in beta, but I haven't encountered any stability issues with it so far.

[amcgee]

Awesome

[amcgee]

Let's update dhis2/workflows with this

[ghost]

I've updated the workflows to address this issue here: dhis2/workflows#18