Skip to content

Implicit creation of pipelines for scan execution policy does not occur under certain conditions

Summary

In 16.2, GitLab released the feature of implicit pipeline creation with scan execution policies if a project does not contain a .gitlab-ci.yml file.

It seems that this "implicit creation" does not occur if:

  • We are using the latest templates for the scanners.
  • There is an Open MR for that branch.
  • New commits are pushed to the branch.

Because this implicit creation does not occur, the MR widget can be stuck on Checking pipeline status, and can block users from merging if Pipelines must succeed option is enabled in the project.

Steps to reproduce

  1. Create a new group.
  2. Create a new project under the group.
  3. Create a Scan execution policy under the group. Use this in YAML mode: 
    type: scan_execution_policy
name: Compliance scanning
description: Scans
enabled: true
policy_scope:
  projects:
    excluding: []
rules:
  - type: pipeline
    branch_type: all
actions:
  - scan: secret_detection
    template: latest
  - scan: sast
    template: latest
  4. Go back to our original project.
  5. Create a new branch. There should be no .gitlab-ci.yml in this branch.
  6. Add a random .rb to for SAST scanning. For example, a file called hello.rb with the contents puts "hello". Push the commit.
  7. Observe a branch pipeline containing SAST and Secret Detection should have run on the branch.
  8. Create a new MR from the new branch to the main branch.
  9. Push a new commit to our new branch. For example, updating the README file.
  10. Observe that no MR pipeline is created.
  11. Go to our Security Policy project. Update the policy to use the default templates instead.
  12. Go back to our project, and push a new commit to our new branch. For example, updating the README file again.
  13. Observe that a branch pipeline will now run containing SAST and Secret Detection.

What is the current bug behavior?

Implicit creation of a pipeline does not occur if:

  • We are using the latest templates for the scanners.
  • There is an Open MR for that branch.

What is the expected correct behavior?

Implicit creation of a pipeline occurs in all situations that a .gitlab-ci.yml file does not exist.

Relevant logs and/or screenshots

Some screenshots when I was reproducing the behaviour for the first time.

Bug image
Switching to default template makes it work image

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

# sudo gitlab-rake gitlab:env:info

System information
System:		Ubuntu 24.04
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	3.2.5
Gem Version:	3.5.23
Bundler Version:2.5.11
Rake Version:	13.0.6
Redis Version:	7.0.15
Sidekiq Version:7.2.4
Go Version:	unknown

GitLab information
Version:	17.7.0-ee
Revision:	1fd574ee571
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	14.11
URL:		https://1.k.git2.cyou
HTTP Clone URL:	https://1.k.git2.cyou/some-group/some-project.git
SSH Clone URL:	git@1.k.git2.cyou:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers:

GitLab Shell
Version:	14.39.0
Repository storages:
- default: 	unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address: 	unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version: 	17.7.0
- default Git Version: 	2.47.0

Results of GitLab application Check

Expand for output related to the GitLab application check 

sudo gitlab-rake gitlab:check SANITIZE=true


Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 14.39.0 ? ... OK (14.39.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Database config exists? ... yes
Tables are truncated? ... skipped
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Cable config exists? ... yes
Resque config exists? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: ...
1/1 ... yes
1/2 ... yes
1/3 ... yes
11/4 ... yes
11/5 ... yes
20/6 ... yes
Redis version >= 6.2.14? ... yes
Ruby version >= 3.0.6 ? ... yes (3.2.5)
Git user has default SSH configuration? ... yes
Active users: ... 3
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x-8.x or OpenSearch version 1.x ... skipped (Advanced Search is disabled)
All migrations must be finished before doing a major upgrade ... skipped (Advanced Search is disabled)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Workaround

  • Use the default templates instead of the latest templates.
  • Create a .gitlab-ci.yml file with a simple Hello World job, so that an implicit creation is avoided.
Edited by Kenneth Chu