Allocate pipeline IID for pipeline execution policy pipelines

What does this MR do and why?

Since !254468 (merged) (19.4), Chain::Seed skips IID allocation for read-only commands. Pipeline execution policy pipelines are built as dry runs, so they lost their IID. CI_PIPELINE_IID was blank while their jobs were seeded, and values expanded at seed time became empty. For example, tags: [docker, $CI_PIPELINE_IID] was stored as ["docker"], which a customer hit after upgrading from 19.2.7 to 19.4.2.

This MR adds Command#allocate_pipeline_iid? (CE: !readonly?). The EE override returns true for policy pipelines. Their jobs are merged into the project pipeline and persisted, so they need the IID. Lint and plain dry runs still skip it.

This brings back the 19.2 behavior: the policy pipeline allocates an IID, is not saved, and gives the IID back (CreatePipelineService#recover_pipeline_iid). So the project pipeline gets the same IID, and policy jobs see the real pipeline IID.

References

• Issue: #633971 (closed)
• Introduced by: !254468 (merged)
• Repro on GitLab.com: https://gitlab.com/gl-demo-ultimate-fayhan/pep-iid-tags/-/pipelines/2950841259

Screenshots or screen recordings

Not a UI change.

Job	Before	After
project job, tags: [docker, $CI_PIPELINE_IID]	["docker", "1"]	["docker", "1"]
policy job, tags: [docker, $CI_PIPELINE_IID]	["docker"]	["docker", "1"]

How to set up and validate locally

1. Create a project and a security policy project, and link them.
2. Add a pipeline execution policy with pipeline_config_strategy: inject_policy and this CI content:

   policy-tagged:
     stage: .pipeline-policy-pre
     tags: ["docker", "${CI_PIPELINE_IID}"]
     when: manual
     script: echo

3. Add the same job (renamed to project-tagged) to the project .gitlab-ci.yml and run a pipeline.
4. In the Rails console, check the tags:

   Ci::Pipeline.last.builds.map { |b| [b.name, b.tag_list] }

   Before this MR, policy-tagged is missing the IID tag. After, both jobs have it.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.