🔒 Sign fails if main branch has new commits since release workflow run started

[rtyley]

On a full Main-Branch release, the release will fail at the 🔒 Sign job stage if anyone has added commits to the default branch while the release has been running - this makes a vulnerable period of several minutes where any push to main branch will break the release:

error: failed to push some refs to 'https://github.com/guardian/thrift-serializer'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

How likely is this to happen?

It seems relatively common:

• https://github.com/guardian/play-secret-rotation/actions/runs/9226539780/job/25386647696#step:8:245
• https://github.com/guardian/play-secret-rotation/actions/runs/9600285702/job/26476255837#step:8:238
• https://github.com/guardian/thrift-serializer/actions/runs/9663268503

...for instance, this would happen if someone started a release, and in the next 5 minutes realised they wanted to update the ReadMe file.

What goes wrong?

The release process is trying to 'fast-forward' the main branch, so that the main branch is just one commit further along from when the release started (with the release commit that the process already created on the release-workflow/temporary/xxx branch) ...but that would mean wiping out that new work on the main branch, and git won't let us do that - not without force-pushing the branch, and we wouldn't want to do that anyway!

gha-scala-library-release-workflow/.github/workflows/reusable-release.yml

Lines 357 to 361 in 23a148a

	if [ "${{ needs.init.outputs.release_type }}" == "FULL_MAIN_BRANCH" ]
	then
	echo "Full Main-Branch release, fast-forwarding the default branch to the release commit"
	git log --oneline -n 3
	git push origin $RELEASE_COMMIT_ID:refs/heads/$GITHUB_REF_NAME

A rule in git is that a 'fast-forward' fails if it would mean rewriting history. This happens if any new commits have been added to the main branch since the workflow run started and captured GITHUB_SHA (the SHA id of the commit that triggered the workflow - the commit we branch from).

Should this be fatal?

Maybe not? We could be more flexible, and do a merge of the temporary-release branch into main, rather than a fast-forward - see PR #40.