Expose per-project pipeline ID ($CI_PIPELINE_IID)
When running a job, we can access several environment variables that are automatically set by GitLab CI/CD.
It is really useful to have a variable that has the following properties:
- it auto-increments every time you run a new pipeline
- it doesn't auto-increment if you retry a job in the same pipeline
- it is small enough to be suitable for being part of a version (like
We already have
$CI_PIPELINE_ID that is good on 1 and 2, but it is not on 3.
It would be great if each project had it's own build version and build number, which are available as secure variables. The build number auto increments after each build and build version is user configurable. Ideally this would also be visible on the "Commits" page.
Build number: 1
Build version: 1.0.$BUILD_NUMBER
Build number is a variable $BUILD_NUMBER
Build version is a variable $BUILD_VERSION
Most modern CI servers have this (TeamCity, appveyor.com), as it is a very useful way of managing versioning.
Expose another variable, called
$CI_PIPELINE_IID or something similar, that increments on a per-project basis, so different projects have completely independent counters. This allows to respect also 3.
Further iterations are:
- Having a per-pipeline job id (
$CI_JOB_IID) with similar behavior
- Using *_IID instead of *_ID in the UI when showing pipelines and jobs (but still keep *_ID for links and urls)
From a real case:
This is the naming convention I use now:
Make sure these are completed before closing the issue, with a link to the relevant commit.
- Feature assurance
- [Documentation] (https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables)
- Added to features.yml
/label ~"feature proposal"