Skipping builds on push to primary branch?

Using Jenkins Ask a question
, ,
1

What’s the best or most common release build practice for build tools that auto-increment a version number?

We have builds with gradle-release and/or npm version that to the major/minor/patch + snapshot edits of their various properties or json files. With an Org folder and multi-branch pipeline, we get webhook event and the builds happen just fine. But then the build automation commits and pushes the version change back to the primary branch… and another event triggers another build.

We’ve put in shared library code to abort the build based on author or commit message, but that seems inelegant and causes the “last build” to always appear aborted.

The readme on github-scm-trait-commit-skip and bitbucket-scm-trait-commit-skip (same code base) state:

The filtering is only performed for change request events, so push events to non-pull requests will be always run.

This seems to exactly exclude what seems to me to be the very reason for such a filter.

Am I doing it wrong? Is the idea of a release build from the primary branch all backwards? If I want a PR approval to trigger a release build, what is the rest of the world doing that I’m missing?

Jenkins setup:

All the very latest from Jenkins helm chart and jcasc.

3

Welcome back, @8N1. :waving_hand:

You’re definitely not alone. This is a pretty common challenge when using auto-versioning in CI/CD setups, especially when everything is wired up to react to webhooks. That infamous loop where a release commit triggers another build (which might even trigger another version bump!) can get frustrating. :person_shrugging:

Here are a few ideas and practices that others have found helpful, maybe some could work in your case too:

:light_bulb: A Few Practices That Might Help

  1. Release from a Dedicated Branch or Tag
    Instead of doing releases straight from main, one approach could be to use a separate release/* branch or push a version tag.
    That way, version bumps, changelogs, and release steps happen outside of your main development flow, and you only merge back into main once the release is finalized. This might help keep things a bit cleaner.
  2. Use [ci skip] for Version Bump Commits
    If your CI system supports it (many do), you might try adding [ci skip] or [skip ci] to the commit message when bumping versions.
    Jenkins can usually honor this too, depending on your setup or plugins
    . It could prevent unnecessary builds caused by automation-only commits.
  3. Filter CI Triggers with Webhook Logic (Where Possible)
    Some tools like GitHub Actions allow filtering based on commit author or message, which could be a handy way to avoid loops.
    Jenkins doesn’t always make this easy out of the box, but maybe you can implement an early-exit condition in your pipeline logic—sounds like you’re already doing something like this.
    Alternatively, the Generic Webhook Trigger plugin might give you more control, if you’re open to adding plugins.
  4. Trigger Releases Only on PR Merges
    Another pattern is to trigger releases only when a pull request gets merged to main, rather than on every push.
    With branch protections in place, this can help ensure that only reviewed changes lead to builds or releases.
  5. Use a Bot Account for Version Bumps
    If you’re pushing version bump commits automatically, it might be useful to do so from a bot or service account.
    Then, in your pipeline, you could detect the commit author and decide whether to skip the build. It sounds like you’re already exploring this path too.

:thinking: Why SCM Trait Plugins Don’t Help Here

You’re absolutely right, as the github-scm-trait-commit-skip plugin and others like it tend to only apply to pull requests or specific event types.
Unfortunately, they don’t do much when it comes to direct pushes, which is where this problem usually shows up.

TL;DR. A Few Takeaways

  • Releasing from main is totally valid, but it gets tricky when automation triggers more automation.
  • Skipping CI for version bump commits (via [ci skip]) might be one of the cleanest ways to break the loop.
  • Releasing from a tag or release/* branch is another option that many teams seem to prefer.
  • If you’re using Jenkins, early-exit logic in shared libraries or pipelines might be the most flexible workaround.

What Other Teams Tend to Do

  • Use [ci skip] to avoid redundant builds.
  • Push version bump commits from a bot and skip builds based on the commit author.
  • Avoid pushing version bump commits entirely—instead, they generate versioned artifacts at release time and leave the main branch untouched.

This is one of those areas where there’s no one-size-fits-all solution, but hopefully one or two of these approaches might help streamline your setup.