Is it possible to update files as part of a merge via GitHub Actions without creating a second commit?

Question

Currently, I'm trying to automate the bump versions for the applications as part of the PR Merge using the GitHub Actions. There is a custom script that would identify the current version of the application and the label attached with the PR and bump the major|minor|patch version accordingly on the file where the version numbers are stored. It is important that the version bump happens only at the time when PR is merged and as part of GitHub Actions because it helps in avoiding the merge conflict in the version file and takes away the manual way of bumping the version.

The GitHub Actions code snippet is given below.

jobs:
  release:
    # Skip on Pull Request Close event.
    if: "!(github.event_name == 'pull_request' && !github.event.pull_request.merged)"
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{ github.ref }}

      - id: bumpversion
        if: github.event.pull_request.merged
        env:
          PR_LABELS: ${{ toJson(github.event.pull_request.labels) }}
        run: bash .github/scripts/bump_version.sh -l "${PR_LABELS}"

The bump_version.sh script has a function given below that makes the version changes and then pushes them to the main branch.

  git config user.email "${GITHUB_ACTOR}@users.noreply.github.com"

  echo "commiting the version bump changes..."
  git add .
  git commit -m "Bump Version v${current_version} -> v${incremented_version}"
  echo "pushing the version bump changes..."
  git push origin dev

This runs fine but the problem is that it makes 2 commits on the main branch when a PR is merged to it. There is a CI/CD pipeline that listens to this main branch for changes and it gets triggered when there is a new commit to it. Since this PR merge makes 2 commits, it is triggered twice.

2 commits for single PR merge image

The question: Is it possible to update files as part of a merge via GitHub Actions without creating a second commit? Is there any other way to achieve a solution to this problem that will help me to bump the version as part of the PR Merge?

There was a similar question yesterday - most of the options are listed in the comments there: https://stackoverflow.com/questions/70274157/gitlab-ci-automatically-increment-version-on-merge-commits — taleodor, Dec 09 '21 at 18:00
The answer in the link recommends storing the version externally. It would be an additional overhead and for multiple microservices running from different repositories, it isn't a feasible solution. Also, after checking the workflow shared in it, I don't think it will solve the 2 commits issue — Sri, Dec 10 '21 at 15:39
1. There is more than a single answer in the link. 2. Regarding external system, we are using this approach for more than a year now for multiple microservices and their bundles and it works perfectly fine. — taleodor, Dec 10 '21 at 16:10

score 0 · Answer 1 · edited Dec 15 '21 at 09:37

My immediate thought is that you could alter the trigger ("on:") in CI/CD to ignore the first of the 2 commits, and only run CI/CD on the second one.

There's a number of ways you could do that, utilizing any of the metadata that comes with a commit. Here's an idea that utilizes the tag. You'd have to refactor the code that defines incremented_version probably, but shouldn't be hard to do in bash.

Here's a CI/CD that would ignore something tagged *.0.0, but would trigger on anything like *.1 or *.0.1:

on:
  push:
    # Sequence of patterns matched against refs/tags
    tags:
      - !v*.0.0
      - !v*.0  # Do not push events to tags v1.0.0, v1.0, v2.0.0, and v2.0, etc.

Personally I like the idea of making the 1st of the 2 commits have an extra .0 and ignoring those. It seems cleaner. After configuring the bash script to do that,:

on:
  push:
    # Sequence of patterns matched against refs/tags
    tags:
      - !v*.0.0 # Do not push events to tags v1.0.0, v2.0.0, etc.

Thanks, @bittahProfessional. Our CI/CD is hosted in AWS CodePipeline. Our initial idea was to ignore the first commit and use the second one as you mentioned. Moreover, we do not want to tag the repository with a version before successfully deploying it to the required environment. So I cannot use tags. — Sri, Dec 12 '21 at 18:16
I thought there would be a natural way to do this in the same workflow. The Workflow starts only when the PR is merged. My requirement is to perform the version bump as the PR Merge even is triggered but only merged after bumping the version. — Sri, Dec 12 '21 at 18:21

score 0 · Answer 2 · answered May 01 '23 at 13:39

0

While I'm in search of a better solution, one option is to amend the commit and force push back into main. I recommend force-with-lease, which fill fail if the force push is not clean. This will require creating a GITHUB PAT, with proper permissions.

  git config user.email "${GITHUB_ACTOR}@users.noreply.github.com"

  echo "commiting the version bump changes..."
  git add .
  git commit -m "Bump Version v${current_version} -> v${incremented_version}" --amend
  echo "pushing the version bump changes..."
  git push origin dev --force-with-lease

answered May 01 '23 at 13:39

Dan Ciborowski - MSFT

6,807
10
53
88

1

Using `git add .` in this case is a huge security risk as it would stage any change anywhere in the working folder. I'd even go as far as to make sure there are no pending changes prior to running this step, deliberately making the changes and then staging only those. – jessehouwing May 01 '23 at 13:44
1

In my actual script, i use "git add src/project/__init__.py", and only add the one file that contains my version number. – Dan Ciborowski - MSFT May 01 '23 at 23:36

Is it possible to update files as part of a merge via GitHub Actions without creating a second commit?

2 Answers2