CODEWITHSUNDEEP
jenkinscontinuous-integrationsemantic-versioning
Carlos Cupeiro
Carlos Cupeiro

Reputation: 51

How to deal Semantic Versioning on Jenkins

I'm beginning on Jenkins in my work place. We use semantic versioning with Teamcity and I want to implement the same on Jenkins. My problem appears when I store the artifacts in builds folder ($JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_NUMBER) because Jenkins use only the build_number to create the folder for build so when I have to reset de Build_number the future artifacts will be stored in the folder of previous builds.

For example:

I have build 1.3.1_develop.1 stored, when I reset Build_Number the next build should be 1.3.2_develop.1 and it should be stored in the folder 1 of build 1.3.1_develop.1

My question is if someone could explain me how to deal with automatic semantic versioning on jenkins because we reset the build number we increase the mayor, minor and patch number.

Jenkins Version: 2.89.4 Jobs--> We use jobs to compile Vuejs for front and to deploy back with python (If this helps)

Thanks for any help.

Upvotes: 4

Views: 9989

Answers (2)

Max Prokopov
Max Prokopov

Reputation: 1336

There is a tool GitVersion which does what you want and it can be integrated with Jenkins or other CI providers.

https://gitversion.net/docs/reference/build-servers/jenkins

Upvotes: 3

jwdonahue
jwdonahue

Reputation: 6659

First thing I notice is you are not using semantic versioning correctly. 1.3.1_develop.1 should be 1.3.1-develop+1. Build metadata should always be preceded by the plus '+' symbol and is not factored into the SemVer sort order.

Second, build number is never "reset", it might roll-over eventually, but it should never be reset. A build number that does not indicate the machine performing the build is also generally useless unless there can only ever be one.

Basically, there's no concept of a build number in semantic versioning. The standard specifies the syntax for build meta data, but is completely neutral on what might be included. Build numbers are generally useless at the level of semantic versioning. They have their uses for preventing directory collisions in CI build systems and even provide a unique identifier for some product lines (Windows for instance), particularly where semantic versioning is not in use (Windows again).

I recommend using a SHA-1 or better hash of the build inputs (Git commit Id for instance) in the build meta tag in addition to any build counter, and use that for your output directory name. You can still use a monotonic counter on your prerelease tags as well, but you would have to create a build output directory name that includes the entire semver string in order to maintain uniqueness.

Third, your build machine is the worst place to archive your build artifacts! Build automation can and does go horribly wrong from time to time. Your build system should not have access to your archive of build artifacts. When your build and initial smoke testing is completed, it should signal a process running on a completely different machine to move the artifacts off the build machine to a more secure location. No process running on the build system should have write access to your archive of build artifacts.

Upvotes: 6

Related Questions