I know what you think: "Updating the version is just one click away. Does it worth it? " It depends.
In our case, we have 6 targets (3 for production and 3 for staging), so what that means is that we have to go through all of the 6 targets and update them each time. And guess what, most of the time we forget about it and then we rush to create a PR to bump the version.
We also noticed that we don't have a procedure in place on when to update the version and that's when the GitHub Actions come into play.
So we came up with this process:
1) A release branch is created from master
2) We create a branch called bump/vX.X.X
and our GA will:
- Checkout the project
- Update the Xcode version (using agvtool) to match the X.X.X on the branch
- Commit the changes
- Create a PR to
master
with the updated version
To achieve this process we came up with the following GA:
name: Bump Marketing Version and Open Pull Request
on:
create:
branches:
- 'bump/v*.*.*'
jobs:
bump-version-and-open-pr:
runs-on: macos-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Set new marketing version
run: |
VERSION=${GITHUB_REF#refs/heads/bump/v}
echo New version will be $VERSION
if [-z "$VERSION"]
then
echo "Error: No version number found in branch name."
exit 1
fi
agvtool new-marketing-version $VERSION
- name: Commit and push changes
run: |
git config user.email "github-actions@github.com"
git config user.name "Github Actions"
git commit -am "Bump marketing version"
git push origin HEAD
- name: Open pull request
uses: peter-evans/create-pull-request@v5.0.0
with:
commit-message: "Bump marketing version"
branch: "${{ github.ref }}"
title: "Version bump"
body: "Version bump"
base: "master"
If you are familiar with GA then you will find this .yml
easy to understand (otherwise, I would advise you to get familiar with the basic concepts and then revisit this post). Just place the file under /.github/workflows
and it's ready to run.
I hope you find this post useful! Happy coding!
Top comments (0)