Security policy violations remain in "running" status indefinitely when no pipeline is created for diff_head_sha
Summary
For projects with merge request approval policies:
When a commit is pushed to a merge request that doesn't trigger a pipeline (due to workflow rules excluding the user/commit), the MR widget gets stuck showing "Checking pipeline status" and "All policy rules must be satisfied" indefinitely.
This is occurring because diff_head_pipeline is nil in this scenario. This ultimately results in the SyncFindingsToApprovalRulesWorker never being executed.
Steps to reproduce
- Configure a project with MR approval policies.
- Utilize the following
.gitlab-ci.ymlto disable pipelines if a specific user makes a commit. - Create a new branch and push a commit.
- Open a merge request.
- Push a new commit from the user you have disabled pipelines for.
- Observe the MR widget stuck on "Checking if merge request can be merged" and "All policy rules must be evaluated" indefinitely
example CI config
workflow:
rules:
- if: $GITLAB_USER_LOGIN == "username"
when: never
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
variables:
AST_ENABLE_MR_PIPELINES: "true"
include:
- template: Jobs/Secret-Detection.gitlab-ci.yml
test:
script:
- echo ""
This can also break the bot comment. An effectively empty violation comment is present.
What is the current bug behavior?
The MR widget is stuck indefinitely "Checking if merge request can be merged" and "All policy rules must be evaluated"
What is the expected correct behavior?
I'm not sure what the best approach is here, given these changes could contain vulnerable code that lack scans in this scenario. Perhaps we should:
- Ensure the checks are updated but failed
- Fix the bot comment, stating that a pipeline containing required security artifacts needs to be present for the latest commit
Relevant logs and/or screenshots
Broken bot comment:
Output of checks
This bug happens on GitLab.com
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.
