### 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 1. Configure a project with MR approval policies. 2. Utilize the following `.gitlab-ci.yml` to disable pipelines if a specific user makes a commit. 3. Create a new branch and push a commit. 4. Open a merge request. 5. Push a new commit from the user you have disabled pipelines for. 6. Observe the MR widget stuck on "Checking if merge request can be merged" and "All policy rules must be evaluated" indefinitely <details> <summary> example CI config </summary> ```yaml 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 "" ``` </details> 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: {width=900 height=215} ### Output of checks This bug happens on GitLab.com ### Possible fixes <!-- If you can, link to the line of code that might be responsible for the problem. --> ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) 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](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads). <!-- If you don't have /label privileges, follow up with an issue comment of `@gitlab-bot label ~"type::bug"` -->