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:

1. it auto-increments every time you run a new pipeline
2. it doesn't auto-increment if you retry a job in the same pipeline
3. 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.

from CI issue: https://gitlab.com/gitlab-org/gitlab-ci/issues/297

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"