Conversation
- Set Version workflow: MAJOR/MINOR/PATCH via workflow_dispatch - Only runs on development branch - Bumps MARKETING_VERSION + CURRENT_PROJECT_VERSION in project.yml - Creates git tag - Build workflow now also supports workflow_dispatch
Add version workflow + manual build trigger
There was a problem hiding this comment.
Pull request overview
Adds GitHub Actions automation to bump the app version/build in project.yml, and enables manual runs of the existing build/release workflow.
Changes:
- Introduce a new workflow (
set-version.yml) to bumpMARKETING_VERSIONandCURRENT_PROJECT_VERSION, commit, and tag. - Allow
build-and-release.ymlto be triggered viaworkflow_dispatchin addition to branch pushes.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| .github/workflows/set-version.yml | New manual “version bump” workflow that edits project.yml, commits, tags, and pushes to development. |
| .github/workflows/build-and-release.yml | Adds workflow_dispatch trigger to allow manual execution. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| VERSION=$(grep 'MARKETING_VERSION:' "$FILE" | head -1 | awk '{print $2}' | tr -d '"') | ||
| BUILD=$(grep 'CURRENT_PROJECT_VERSION:' "$FILE" | head -1 | awk '{print $2}' | tr -d '"') | ||
|
|
||
| IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION" | ||
|
|
There was a problem hiding this comment.
VERSION/BUILD are parsed from project.yml and then used in arithmetic without validating that they were found and are numeric/semver (e.g., empty or malformed values will make the bump logic fail or write an invalid version back). Add explicit checks that VERSION matches ^[0-9]+\.[0-9]+\.[0-9]+$ and BUILD is an integer before proceeding, and emit a clear error if parsing fails.
| git commit -m "Version $NEW_VERSION (build $NEW_BUILD)" | ||
| git tag -a "v$NEW_VERSION" -m "Release v$NEW_VERSION" | ||
| git push origin development |
There was a problem hiding this comment.
This workflow creates and pushes an annotated vX.Y.Z tag on development. That can conflict with the build/release workflow (which also creates/releases v$VERSION on main) and can result in releases pointing at the wrong commit or failing if the tag already exists. Consider removing tag creation here, or only tagging when the release is cut on main (or ensure the downstream release step targets the correct commit).
| git commit -m "Version $NEW_VERSION (build $NEW_BUILD)" | ||
| git tag -a "v$NEW_VERSION" -m "Release v$NEW_VERSION" | ||
| git push origin development | ||
| git push origin --tags |
There was a problem hiding this comment.
git push origin --tags will push all local tags, not just the newly created release tag, which is risky if other tags exist on the runner checkout. Push only the specific tag you just created (e.g., v$NEW_VERSION).
| git push origin --tags | |
| git push origin "v$NEW_VERSION" |
| on: | ||
| push: | ||
| branches: [test, beta, main] | ||
| workflow_dispatch: |
There was a problem hiding this comment.
Adding workflow_dispatch allows this expensive/signing/notarization workflow to be triggered on any branch/ref by anyone with dispatch permissions. If that’s not intended, add a branch guard (or an input + validation) so manual runs are limited to test/beta/main, matching the push trigger.
.