I'm curious about best practices for handling release builds, particularly with build tools that automatically increment version numbers. We currently use `gradle-release` and `npm version`, which modify versioning information in various configuration files. In our setup with a multi-branch pipeline and an Org folder, everything works great—the webhook triggers our builds just fine. However, the automation then commits and pushes the version changes back to the primary branch, which leads to yet another build being triggered.
To manage this, we've implemented some shared library code to stop builds based on commit authors or messages, but it feels clunky and leaves the last build status labelled as aborted. I came across documentation for the Jenkins plugins like [github-scm-trait-commit-skip](https://plugins.jenkins.io/github-scm-trait-commit-skip/) and [bitbucket-scm-trait-commit-skip](https://plugins.jenkins.io/bitbucket-scm-trait-commit-skip/), which mention that filtering only occurs for change request events, meaning push events won't be skipped.
This makes me wonder if I'm approaching the release build process incorrectly. Is the whole concept of pushing from the primary branch to trigger a release build backward? What are other teams doing in this context that I might be overlooking? Here's a quick overview of our process:
1. PR -> Jenkins checks out and merges provisionally with main -> build and test -> report success to Bitbucket.
2. PR Approved -> merged with main, version tag updated, built artifact created -> commit and push release version -> increment for future dev -> push to main.
Deployments are managed through JIRA approvals or manual triggers using Ansible jobs.
3 Answers
In our practice, the only long-lasting branch we have is the master, and we create feature branches from it. PRs are used for code reviews, and once merged, they trigger CI workflows that utilize semantic-release. This includes incrementing version numbers, updating changelogs, committing those changes, tagging the release, and building the relevant artifacts. Each release is automatically deployed to our test environment.
I like to keep versioning out of the main and development branches completely. Instead, I handle version pushes to a separate branch that manages the source along with version info. This reduces unnecessary build triggers on the main branch.
We manage things by creating staging builds and then releasing on tagged commits. When a merge goes through to main, it’s considered ready for release. We test first and if everything passes, we move forward by pushing a pre-release version with a `[skip ci]` label to avoid triggering another build. Once merged, we strip that label and commit again, then build and deploy to staging. Afterwards, we wait for release approval before bumping the version and tagging it for deployment.
Thanks for sharing! This gives me some ideas. But just to clarify, does the 'PR' have a build associated for testing? What does 'pre-release' mean in your process? Is that after the initial build and test?
I'm curious, do you rebuild for each release or just promote the existing artifact? It sounds like the version changes at that stage, what does that look like?
Sounds similar to our method. When you merge into master, how do you prevent the automatic version increment commits from triggering another build?