Report metadata from Build Jobs to Job UI
Problem to solve
When we run builds, there are a few things we keep track of when the build is done. Gitlab handles whether a build fails or succeeds, the log, etc. But we'd like to also track: The version of the produced binary, a version of a few specific dependencies, etc.
Target audience
Developers, and release folks in general. Perhaps Q/A teams as well.
Further details
Proposal
Appveyor, and probably other build systems, have a way of reporting individual values back to the build system. This way, you can control f.ex. the version Appveyor shows as having been built, by calling (f.ex.) Update-AppveyorBuild -Version "$version build $env:APPVEYOR_BUILD_NUMBER"
in powershell.
Phase 1
I suggest that the build log includes a special marker (exactly like the step start/end times right now) that tells what a certain value should be. This marker could be update_value:KEY:VALUE
, or update_value:sdk-version:1.2.3.4-alpha
and update_value:version:1.4.4-alpha
. Being a marker in the log, no additional API's need to be created, and individual users/scripts can output their own values simply by writing to the console.
Gitlab already contains code to hide all markers (identified by a certain ANSI escape code), meaning it would work (not show in the build log) in both old and new versions out of Gitlab.
Last-value wins, in cases of duplicates.
Phase 2
Once the build is done (or while it's being completed) the values can be parsed and presented in the Gitlab UI (and API), f.ex. here:
Phase 3
Once indiviudal builds can report values, it makes sense to report them for a pipeline. In our setup, a given pipeline produces, tests and publishes a single version. It makes sense for us to report the "version" attribute for the entire pipeline, and not just a single job.
These could be reported as a form of Job Name, KEY: Value
(to allow duplicate keys between jobs). Ideally, those in charge of the build ensure that no duplicates occur.
What does success look like, and how can we measure that?
That we can report custom values from a build log and display them.