Allow users to commit to the main branch while full release running

[rtyley]

This should fix #37 - ie, a Full Main-Branch release should still succeed, even if someone adds additional commits to the main branch while the release workflow is running.

Note that this change in behaviour only applies to Full Main-Branch releases, not Preview releases, as Preview releases don't ever attempt to update any branch.

Avoid making a merge commit if possible

To avoid the noise of an additional merge commit (ie a 3rd commit) we prefer a fast-forward, and only create a merge commit if it's necessary - that's when someone has done additional commits on the main branch.

These diagrams show how the resulting git history will look after a release:

A release where no extra work was done on main branch (fast-forward possible)

---
config:
  gitGraph:
    parallelCommits: true
    showCommitLabel: true
---
gitGraph
   commit id: "commit before release"
   commit id: "release commit" tag: "v1.0.0"
   commit id: "set snapshot"

Loading

A release where extra work added to main branch during release (requires a merge)

---
config:
  gitGraph:
    parallelCommits: true
    showCommitLabel: true
---
gitGraph
   commit id: "commit before release"
   branch release-workflow/temporary/xxx
   checkout release-workflow/temporary/xxx
   commit id: "release commit" tag: "v1.0.0"
   checkout main
   commit id: "extra work" type: HIGHLIGHT
   merge release-workflow/temporary/xxx
   commit id: "set snapshot"

Loading

Two full Main-Branch releases can't run concurrently

Although we can now handle extra work on the main branch, running two releases at once is not recommended!

Using the GitHub API to create & merge commits, rather than git

We're now using the GitHub API, rather than git, to do both these operations:

• Update the branch to try fast-forwarding - using the GitHub API means we don't need to clone a deep history of the repo to make that update
• Merge the branch if the fast-forward fails - using the GitHub API means that the merge commit will be signed/verified by GitHub too, just like other commits created by the GitHub App.

Testing

Here are two successful full-main-branch release runs using this branch:

• No extra commits ...fast-forward of default branch to include release commit succeeded
• Extra commits during release

  gh: Update is not a fast forward (HTTP 422)
  ...fast-forward failed (commits added to default branch while release running?), will attempt a merge instead
  

  

[rtyley]

GitHub API: POST /repos/:owner/:repo/merges merges a branch (that doesn't need to be a PR branch) into the base branch.

[rtyley]

GitHub API: PATCH /repos/:owner/:repo/git/refs/heads/{branch_name} updates a branch to point at a new commit. It only allows fast-forward changes - not rewriting history, unless you use the force param - and we don't.

Previously we used git push origin $RELEASE_COMMIT_ID:refs/heads/$GITHUB_REF_NAME to do this, but using the GitHub API, we don't need to rely on cloning enough of the git repo's history (fetch-depth: 2) to find the old position of the branch.

[Divs-B]

Thanks for already working into this @rtyley 👍 we recently had error in release when additional merge happend while the release was in progress so looking forward to have this change.

Changes looks really promising 🌟 specially where you are telling either to 'point' to additional commit because i think when branches are not divergent or to do 'merge' if they are . (please corect if this not sounds right as i am not experienced much in these).

[rtyley]

specially where you are telling either to 'point' to additional commit because i think when branches are not divergent or to do 'merge' if they are

Thanks @Divs-B! Yep, this bit here:

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

Lines 353 to 358 in 5f9ba7b

	if gh api --silent --method PATCH /repos/:owner/:repo/git/refs/heads/$GITHUB_REF_NAME -f "sha=$RELEASE_COMMIT_ID"; then
	echo "...fast-forward of default branch to include release commit succeeded"
	else
	echo "...fast-forward failed (commits added to default branch while release running?), will attempt a merge instead"
	gh api --silent --method POST /repos/:owner/:repo/merges -f "base=$GITHUB_REF_NAME" -f "head=$RELEASE_COMMIT_ID"
	fi

The first attempt, trying to do the 'fast-forward', is in the if statement condition on line 353 - and only if that fails do we get to line 357 where instead we do a merge.

Thanks so much! Is the PR ok for you to approve?

[Divs-B]

Thanks @rtyley for explaining above. The PR looks good to go, cant wait to test 🙌

[rtyley]

The PR looks good to go, cant wait to test 🙌

Oh yeah, go commit-crazy during releases!