How to Tag a Jenkins Build Itself (Not a Git Tag)

Community
1

Hi everyone,

I’m using Jenkins for CI/CD and I wanted to ask:

Is there a way to tag or version a Jenkins build itself, similar to how GitHub Actions creates a release or tag after a successful workflow?

To clarify — I’m not looking to tag a Git repository. Instead, I want to assign a version label (e.g., v1.0.5) directly to a Jenkins build, so it’s visible in the UI or accessible via the Jenkins API.

I’ve considered using the build description or the Build Name Setter plugin, but I’d like to know:
I’ve considered using the build description or the Build Name Setter plugin, but I’d like to know:

  • Is there a standard or recommended way to tag/version Jenkins builds?

  • Can this be automated via pipeline or REST API?

  • Is there any plugin or best practice for managing these version labels?

Thanks in advance for any guidance!

2

I would say the Badge plugin is closest to what you want. You can add badges as pipeline steps

3

thanks for your reply
Is there any jenkins api to create version or by default?

4

There are probably a bunch of different ways to approach this.

Versioning is often handled by your build tool (Jenkins is an automation tool), and you can often ask the build tool what version it is building. I have some pipeline code that can create a version number for the build tool by first asking the build tool what version it knows about and then adding specifics like branch information to the version. I pass that back to the build tool as information that it can then use to build based on corporate rules. However, once I have that information, it’s just as easy to add in a currentBuild.description = revisionString so that it shows up in the Jenkins UI

5

Or I could use addBadge with the version information into the pipeline.

6

Rereading the question, I think I see some data we may have missed. If you are trying to add information to the Jenkins build itself during a build, this is trivial in a pipeline script as mentioned above.

If you are looking to add it as a post step following some manual acceptance, I know you can manually add a description to any build. I am not familiar with automating it via REST.

Regarding your question on there being a standard way to tag these builds or best practices: it’s up to your development shop to create those standards. A good best practice with Git repositories is to keep branches as short-lived as possible and have your repository be the source of truth for all things versioned. Your CI system is irrelevant in this case. When you delete the branch after merging a release, Jenkins forgets about it and removes all of its data around that, including your metadata marking the release version. The preceding sentence includes assumptions about developer workflow regarding repositories and branches.

You mentioned GitHub Actions, keep in mind that GitHub is much, much more than Git itself. A Release is part of GitHub and something that Jenkins does not mimic itself. A tag is in your code repository; a Jenkins pipeline would also be capable of adding a tag to a commit and pushing that back to your Git repository (which you clarified that you’re not trying to do)