Commit same changes on multiple branches

[zaniluca]

Hi! I was trying to figure out if it was possible to commit the same changes that happened in the workflow to multiple branches, my use case is pretty simple:

I have a workflow that builds and updates the buildNumber in a .json file during the process, I want to commit the changes to both my production and my master branch; the build only happens on push events on production

Right now my action does something like this:

      - name: Bump build and tag on master
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          branch: master
          commit_message: "chore: bumped build numbers"
          commit_options: "--no-verify"
          tagging_message: "v${{steps.version.outputs.prop}}"

However, if I try to update both branches in sequence i get no commit from the second one (because there are no changes to commit, they were already committed on master!)

      - name: Bump build and tag on master
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          branch: master
          commit_message: "chore: bumped build numbers"
          commit_options: "--no-verify"
          tagging_message: "v${{steps.version.outputs.prop}}"

      - name: Bump build and tag on production
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          branch: production
          commit_message: "chore: bumped build numbers"
          commit_options: "--no-verify"
          tagging_message: "v${{steps.version.outputs.prop}}"

Is there a git setting I'm not aware of I need to toggle to achieve this?
Thanks!

[stefanzweifel]

There is no secret setting in git-auto-commit to make this workflow possible. But I see 2 ways to solve your problem:

1. Have 2 identical jobs in your workflows that bump buildNumber. One job pushes the changes to master the other to production.
2. Have 1 job in your workflow but instead of running git-auto-commit-action twice, the second step cherry picks the commit from one branch to the other.

The workflow for solution 2 would look something like this. (Haven't tested this on GitHub Actions, but should work as it's just a chain of basic git commands)

  - name: Bump build and tag on master
    uses: stefanzweifel/git-auto-commit-action@v4
+   id: auto_commit
    with:
      branch: master
      commit_message: "chore: bumped build numbers"
      commit_options: "--no-verify"
      tagging_message: "v${{steps.version.outputs.prop}}"


-- name: Bump build and tag on production
- uses: stefanzweifel/git-auto-commit-action@v4
- with:
-   branch: production
-   commit_message: "chore: bumped build numbers"
-   commit_options: "--no-verify"
-   tagging_message: "v${{steps.version.outputs.prop}}"
+ - name: Bump build and tag on production
+   run: 
+     git fetch origin
+     git checkout -b production origin/production
+     git cherry-pick ${{ steps.auto_commit.outputs.commit_hash }}
+     git tag -a "v${{steps.version.outputs.prop}}" ${{ steps.auto_commit.outputs.commit_hash }}
+     git push --follow-tags --atomic --set-upstream origin production

A couple of problems you might run into:

• production-branch might not be able to be checked out, depending on how you use actions/checkout (hopefully git fetch origin works here)
• such a workflow would create 2 tags named "v1.0.0" but they will be associated with different git commit shas (depending on your GitHub setting, you will see the tags from master or production in GitHub's UI anyway)
  • (I think this could lead to merge-conflicts down the line, if you should ever merge production into main or vice versa)

[zaniluca]

@stefanzweifel thank you for the fast reply! your 2nd proposed solution could work quite well for my use case.

To prevent conflicts I can actually skip the tagging on production, I may just keep the commit with the changes to the buildNumber.

This means I can remove:

git tag -a "v${{steps.version.outputs.prop}}" ${{ steps.auto_commit.outputs.commit_hash }}

and simply do:

git commit -am "chore: bumped build numbers"

Am I right?

About this:

production-branch might not be able to be checked out, depending on how you use actions/checkout (hopefully git fetch origin works here)

This is the way i use actions/checkout

      - name: Checkout repository
        uses: actions/checkout@v2

Seems problematic for you?

Thanks again!

[stefanzweifel]

If you use git cherry-pick, you won't have to pass a commit message.
So you can just remove "git tag" and "--follow-tags and --atomic" from "git push".

I think the way you use "actions/checkout" should work. From past experience I know that sometimes it can be a problem to get Actions to fetch information from a repository without setting "depth: 0".

Best way is to just give it a try and tweaks options as you go along.