Pipeline Execution Policy with override_project_ci changes variable precedence of included non-policy jobs

Summary

When including the project CI via an override_project_ci PEP, the variable precedence of project YAML jobs doesn't work as expected.

Steps to reproduce

  1. Create new project with this CI configuration: 
    project-job:
    variables:
      MY_VAR: "Project job variable value"
    script:
      - echo $MY_VAR
  2. Add a variable MY_VAR with Project configuration variable value in the project settings
  3. Set up a PEP with override_project_ci and the following policy CI YAML: 
    include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_SHA
    file: $CI_CONFIG_PATH

override-job:
    script:
      - echo $MY_VAR
  4. Run pipeline in project
  5. Observe Project job variable value in the output of project-job (unexpected behavior), but Project configuration variable value in the output of override-job
  6. Disable the policy
  7. Run pipeline in project
  8. Observe Project configuration variable value in the output of project-job (expected behavior)

Example Project

Full reproduction in this group: https://gitlab.com/gl-demo-ultimate-mgrabowski/i-510867

What is the current bug behavior?

This job ignores the existence of the project-level variable and outputs the lower-precedence job-level variable value instead.

What is the expected correct behavior?

That job should output Project configuration variable value as project-level variables have higher precedence than job-level variables.

Relevant docs

Our docs say:

Variables can be shared with pipeline execution policies using group or project settings. If a variable is not defined in a pipeline execution policy, the value from group or project settings is applied. If the variable is defined in the pipeline execution policy, the group or project setting is overwritten. This behavior is independent from the pipeline execution policy strategy.

The policy YAML does not define MY_VAR, so the value from the project configuration should be used. It should not just happen for the policy jobs, but for the included jobs as well. (Just as it would behave when one would perform that include "normally".)

Output of checks

This bug happens on GitLab.com

Edited by Manuel Grabowski