## Summary Users are unable to use predefined variable `CI_COMMIT_REF_PROTECTED`, protected variables, or the `ref_protected` JWT claim in merge request pipelines even if one or both of the branches are protected. ### User problem Users rely on being able to determine if a pipeline is run on a protected ref in order to secure their workflows. For example, users can use our [Vault integration](https://docs.gitlab.com/ci/yaml/#secretsvault). They may setup their Vault secret to only be accessible to protected branches. If a user creates a merge request from a source branch that is protected and is targeting another protected branch, that user can no longer access their protected variables/secrets in the merge request pipeline. ### Proposal 1. Create a project setting under the `Protected branches` setting that is disabled for past projects, but enabled for future projects. 2. This setting would allow for (source-protected, target-protected) merge-request pipelines to be considered protected, giving them access to protected variables. ### Tasks 1. Create a new project setting called `protect_merge_request_pipelines` . This is to ensure that we DO NOT break existing pipelines when we make the change in behavior for `CI_COMMIT_REF_PROTECTED` and `ref_protected` - [x] Add new db column `protect_merge_request_pipelines` to `project_settings` table with default value false - [x] Backend changes to let users update this new project setting - [x] Frontend changes to display and update this new project setting - [x] Set the value of this new project setting as true for new projects 2. Modify the behavior of `CI_COMMIT_REF_PROTECTED` and `ref_protected` . Set the value as `true` ONLY if the project setting is enabled and both source and target branch of the MR are protected 3. Rollout the Feature Flag 4. Update documentation 5. Cleanup the feature flag