CODEWITHSUNDEEP
jenkinscontinuous-integrationtaggingbuild-system
sorin
sorin

Reputation: 170498

Strategy regarding tagging in source control from the continuous integration build systems

This is a question about how we should use tagging from the continuous integration system.

Clearly, the build system will try to build for most commits, skipping some of them if they are too close one to another, giving a build number for each of them.

The result of the build can be one of the following: * build-system-failure (not enough disk space on build machine or similar) * build-failure * test-failure * success

Now the big question is if it would be a good idea or not to store this information inside the SCM (usually git or mercurial).

Using tags to mark these seem like a nice idea, allowing you do do things like:

  1. record a tag build=1234 on the revision
  2. move the tag last-success to the current build if is a success
  3. move the tag last-build to the last build (that did not pass the tests)
  4. add a tag build_url=http://buildsystem.example.com/job/1234
  5. maybe other changes?

Now I am also wondering about spamming the SCM history with tag updates from the build system.

Is this the proper approach? -- I do still have some concerns regarding putting too much information into the SCM and having too many email notifications as a side effect.

Upvotes: 1

Views: 227

Answers (1)

robjohncox
robjohncox

Reputation: 3665

Essentially this looks like it boils down to making sure you can trace from a given build back to the source code that created it (and vice versa) - I have seen two general approaches to solving this

  1. The solution you mention - mark the code in the SCM with the build number (with tagging being the obvious way to do this)
  2. The opposite - store the revision number from the SCM inside the package produced by your build (for example have the build spit out a small text file containing the SCM revision number that gets included in the package).

I would say that both of these solutions work quite well, and the best one to use depends on how you intend to use this information. For example, if your motivation is that, when debugging an issue on a production system, you can easily check out the relevant source code for that software version, then approach (2) works well as it is easy to look up the SCM revision number on your production system and check out the code for that revision. However, you also have a number of good reasons for preferring option (1) listed in your question, so I would go with that.

To your point about controlling email spam - personally have never found a good way of stopping build systems from being spammy, I think the best strategy is to make it easy for people to filter this out if required (i.e. subject headers that can be used in email rules, or sending all mail to a shared email address specifically for build spam). Sorry I don't have a more useful suggestion.

Kudos for making your builds traceable back to the source code!

Upvotes: 2

Related Questions