Setting workflow:name: in a Pipeline Execution Policy clears the value clear instead of setting it

Summary

• The display name for a pipeline can be set with workflow:name: - this changes the 'pipeline title' from being automatically set to the commit message to being set to the value of workflow:name:
• Setting workflow:name: in a Pipeline Execution Policy to a non-null value will still result in the pipeline name being set to null

Steps to reproduce

1. Create a new project with the following configuration:

workflow:
  name: "pipeline name test"

test-job:
  script:
    - echo "This is the test job" 

2. Commit the job and observe on the Pipelines page that the name of the pipeline is set to pipeline name test
3. Create and apply a PEP to the project - for convenience, here is a policy you can save as pep-policy.yaml for testing:

# workflow:
#   name: "set by PEP"

pep-job:
  script:
    - echo "This is the PEP job"

4. Uncomment out the workflow:name: directive and trigger the pipeline, observe that the new pipeline's title will be set to the commit message

Example Project

• I tested this in my ultimate sandbox here

What is the current bug behavior?

• Instead of setting the value correctly, PEPs overwrite the workflow:name: value with null

What is the expected correct behavior?

• If the PEP does set workflow:name: the PEP-set value should be displayed
• If the PEP does not set workflow:name: the .gitlab-ci.yml-set value should be displayed

Relevant logs and/or screenshots

• If workflow:name: is set in .gitlab-ci.yml but not the PEP:

• If workflow:name: is set in the PEP but not the main config file:

• If workflow:name: is set in both the PEP and .gitlab-ci.yml files:

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.