Skip to content

feat(#24) support play stores#25

Open
andrew-codes wants to merge 2 commits intomsp1974:devfrom
andrew-codes:24-increment-version-code
Open

feat(#24) support play stores#25
andrew-codes wants to merge 2 commits intomsp1974:devfrom
andrew-codes:24-increment-version-code

Conversation

@andrew-codes
Copy link
Copy Markdown
Contributor

@andrew-codes andrew-codes commented Mar 25, 2026

This pull request introduces a set of improvements to the build and release workflow for the project, primarily focusing on automating version management during manual releases.

Build and Release Workflow Automation:

  • Added manual workflow dispatch inputs (version_bump and is_beta) to .github/workflows/build-action-artifacts.yml, allowing users to specify the type of version bump (patch, minor, major) and whether the release is a beta.
  • Automated calculation and updating of the version name and version code in app/build.gradle.kts based on workflow inputs, including incrementing the version code and tagging the release in Git.
  • Updated the release creation step to use the new version and prerelease status dynamically, ensuring GitHub releases are correctly tagged and marked as pre-releases if applicable.

Developer and release workflow recommendation

Note none of this is required for this PR. More so recommendations on how to get the most out of the PR and ensure low overhead for you and contributors.

  • use main branch as repo's primary target branch.
  • branch features off main and PR into main (or you could simply commit to main)
  • When ready to release, manually trigger workflow with release type and if its beta.
  • Currently only one beta is supported at a time; can be addressed by a follow up PR to change this.

I also recommend if you need to update your feature branch with new changes from other PRs that have merged to main, to do so via git pull --rebase origin main on your feature branch. This will create and keep a clean and linear git history which makes troubleshooting, git bisect, reverts, etc. much more straight forward.

The reason I recommend branching off main for a feature and merging it into main via PR: run tests on PR to validate. Only merge when feature is ready. It helps keep main releasable at all/or most of the time. This is important given if this is not the case, you have to manually keep track of what commit/when main is stable enough to release. This also is the same process for external contributors.

@andrew-codes
Copy link
Copy Markdown
Contributor Author

Please let me know if you have questions or if this requires any changes. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant