Automatically merge up release commit on pre-release #81
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
golang/pre-publish/action.yml
Outdated
| - name: "Determine branch to merge up to" | ||
| if: ${{ inputs.push_changes }} | ||
| id: get-next-branch | ||
| uses: alcaeus/automatic-merge-up-action/get-next-branch@main |
There was a problem hiding this comment.
Can we use the current commit instead (b253eae7dfccc0b637edf71121608375e07a7678 as of right now).
There was a problem hiding this comment.
Good point. Updated.
| shell: bash | ||
| run: | | ||
| git checkout ${NEXT_BRANCH} | ||
| git merge --strategy=ours ${RELEASE_BRANCH} |
There was a problem hiding this comment.
Part of the release process bumps the patch version. Would this end up creating a PR to bump the version on a minor release > that the one being targeted by the action? For example if you are releasing 2.1.1 and a I release/2.2 branch exists would a PR be merged up to release/2.2 that attempts to change the version to 2.1.1? I would expect all other changes to release/2.1 to have already been merged up to release/2.2.
There was a problem hiding this comment.
No. Let's assume you are releasing 2.1.1. Pushing that commit would usually trigger a pull request to merge that change into release/2.2. You'd have to manually ignore the changes in that one and merge the commit as merged.
With this change, we're manually merging the bump commit into the release/2.2 branch, but by using the ours strategy, no changes will be applied. Since release/2.2 then receives a push, it will trigger a merge-up of the commit (with no changes) to the next branch.
The main difference here is that this takes care of the first merge-up PR that would require manual intervention to not change the version in any newer branches. From there, it's just a straightforward approval to enable auto-merge until the end of the chain.
3 participants
This change integrates the automatic-merge-up-action into the Go pre-release process.
If no push is requested, the behaviour does not change. However, when a push is requested, we determine the next branch (e.g. release/2.2 when releasing a 2.1 patch release) and merge the changes using the
oursstrategy. This marks the bump commit as fully merged up without accepting its changes. This removes the need for manually handling the merge-up pull request created due to pushing the new commit during the release process.