Expose per-project pipeline ID ($CI_PIPELINE_IID)
Description
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
$MAJOR.$MINOR.$ID
)
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.
Example:
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.
Proposal
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)
Documentation blurb
Use cases
From a real case:
This is the naming convention I use now:
STABLES_FILE_NAME: "${CI_PROJECT_NAME}-${CI_BUILD_REF_NAME}-build-${CI_PIPELINE_IID}"
Feature checklist
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"