Allow surfacing build metadata such as version generated by CI/CD

Problem to solve

It's hard to keep track of builds based on their commit id. Other CI systems allow the pipeline to set a semantic version which identifies the build. Gitlab should have this feature.

Today, we need to go into the build log to identify the version of the produced package, this is very cumbersome.

Target audience

Anyone using Gitab CI, especially if producing some versionable artifact (docker image, package, etc)

Further details

Proposal

All our builds produce a semtantic version (auto-generated by the build). In some build systems, the CI pipeline can expose this simply by printing the version to stdout prefixed by some special characters (###GITLAB_BUILD_VERSION_2.3.0 or whatever).

It should be a per-project setting if the build was allowed to replace the "commit id" (which today is what identifies a build) with the generated semver. If yes, this would be what identified the build throughout gitlab instead of the current commit id.

This ties nicely into the deployment integration gitlab is building as well. Many shops deploy a semver-based version of a package, not a commit id. Its much harder to reason about "hey, after we deployed cx45453098234098 things started failing" than "hey , v2.0.2 seems to be failing".

What does success look like, and how can we measure that?

See above

Links / references

Teamcity's documentation of comparable features: https://confluence.jetbrains.com/display/TCD9/Build+Script+Interaction+with+TeamCity#BuildScriptInteractionwithTeamCity-ReportingBuildNumber

Edited Mar 15, 2019 by Trond Hindenes
Assignee Loading
Time tracking Loading