elaborate on what the difference between ID and IID is

What does this MR do?

In a recent project we tried to use PIPELINE_ID or PIPELINE_IID in a GitLab CI pipeline. However we got confused and side tracked whether these numbers are unique, continuously increasing id's and what their scope is.

Based on my observations and discussions online I would like to slightly adjust the documentation to clarify the difference more. It's a small change, but hopefully it will help clarify any confusion.

I also applied the changes to CI_MERGE_REQUEST_ID and CI_MERGE_REQUEST_IID, because they might face the same confusion.

What should be changed?

Pipeline ID

CI_PIPELINE_ID

The instance-level ID of the current pipeline. This is a unique ID across all projects on GitLab.

CI_PIPELINE_IID

The project-level IID (internal ID) of the current pipeline. This ID is unique for the current project.

Merge Request ID

CI_MERGE_REQUEST_ID

The instance-level ID of the merge request. Only available if the pipelines are for merge requests and the merge request is created. This is a unique ID across all projects on GitLab.

CI_MERGE_REQUEST_IID

The project-level IID (internal ID) of the merge request. Only available If the pipelines are for merge requests and the merge request is created. This ID is unique for the current project.

Documentation site

Affected documentation page: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

Potential additional change

I'm debating if it would be helpful to include that it's a monotonically increasing counter, but I wasn't sure if that was too much detail. Also I'm just assuming that it is based on most id-based implementations and haven't verified that by looking at the code or empirically testing this through the GitLab API's.

Screenshots (strongly suggested)

The screenshots show the state before applying any changes.

PIPELINE_ID and PIPELINE_IID

CI_MERGE_REQUEST_ID and CI_MERGE_REQUEST_IID

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team