Scan execution policies with target_default/target_protected do not run in merge requests without .gitlab-ci.yml file and/or MR configuration

Summary

Hey team, we are seeing some odd behavior w/ a customer that is in the midst of rolling out security 
policies, specifically scan execution.  We are observing if a project doesn't have a .gitlab-ci.yml file 
the scan execution policy doesn't trigger/create jobs for MR events.  This is the case when we use the 
new "Merge Request Security" strategy template.  Subsequently, when the MR is merged into the detault 
branch, the scan jobs are triggered.  Is this working as expected or a bug?  From reading our docs  (2nd 
paragraph), it seems like a bug.
scan jobs aren't being created when merge_request_event is set in the policy, unless there is already a 
.gitlab-ci.yml file in the project and it explicitly configures merge request pipelines.  Any other 
scenario (no .gitlab-ci.yml file, or no explicit configuration of merge request pipelines) and the scans 
don't run.
rules:
      - type: pipeline
        branch_type: default
      - type: pipeline
        branch_type: target_protected
        pipeline_sources:
          including:
            - merge_request_event

Documentation

Steps to reproduce

  1. Create a project without a .gitlab-ci.yml
  2. Create a policy that uses target_default/target_protected
  3. Create a merge request targeting the default/protected branch

Example Project

https://gitlab.com/gl-demo-ultimate-azwickey/security-sandbox-customer-y/spring-example/-/merge_requests/4

https://staging.gitlab.com/govern-team-test/alexander-test-group/no-gitlab-ci-yml

What is the current bug behavior?

If a project doesn't have a .gitlab-ci.yml file the scan execution policy doesn't trigger/create jobs for MR events

What is the expected correct behavior?

If a project doesn't have a .gitlab-ci.yml file, the scan execution policy does trigger/create jobs for MR events

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Current workaround

Setting branch_type: all and actions to have template: latest will create scan jobs for merge request pipelines when there is not a .gitlab-ci.yml present.

The downside of this is that they will have all their branches have scanning since branch_type: all is not as targeted as branch_types target_default/target_protected.

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.

Edited by Alexander Turinske