Skip to content

Support allow merging of MR when Pipeline must succeed is enabled in absence of pipeline

Problem to solve

  1. Currently, if an MR does not contain a pipeline it cannot be merged.
  2. With :changes keyword, users can control what kind of changes the pipeline/individual jobs would run for. When they make changes to a file or branch for which the pipeline is configured not to run, and Pipeline must succeed is enabled, the widget considers that as an unresolved item and displays a generic message: You can only merge once the items above are resolved. With no indication of what is it that needs to be resolved, because a pipeline never ran.

Four use-cases as specified in #247074 (closed)

The "Troubleshooting CI/CD" page says, in the "Checking pipeline status" section:

This message is shown when the merge request has no pipeline associated with the latest commit yet. This might be because:

  • GitLab hasn't finished creating the pipeline yet.
  • You are using an external CI service and GitLab hasn't heard back from the service yet.
  • You are not using CI/CD pipelines in your project.
  • The latest pipeline was deleted (this is a known issue).

For the first case, it should say something such as "Waiting to create the pipeline" to indicate that the user needs to wait for GitLab to create the pipeline. If more information, such as, if the attempt to create the pipeline is stuck in a queue, is available, it should report that (and the queue position, if that's available - "there are 4 callers ahead of you").

For the second case, it should say something to indicate that it's waiting for some external CI service to respond - and indicate what service that is, if that makes sense.

For the third case, is there even a pipeline status to check? If not, it shouldn't be trying to check it.

The fourth case appears, from what I read of the issue, to be a known bug.

Proposal

We need two things:

  1. The mergeability check needs to know if the pipeline configuration has been processed for the current source head SHA

    • This can be a persisted in the merge_requests table
    • Possible complication: Different pipeline sources are processed at different times, but all contribute to the "successful pipeline" status. For example:
      • Push pipelines are started synchronously when processing the push
      • merge request pipelines are started asynchronously when processing the push
      • Pipelines can also be triggered manually

    This means we may need to store multiple SHAs. For example, we know a push to a branch has been processed only if both the merge request pipeline config commit SHA and the branch pipeline config commit SHA are up-to-date.

  2. The mergeability check needs to know if a non-existent pipeline can be considered success

    • This can be new project setting, for example "Wait for external CI" under "Pipelines must succeed".
    • A generalization of that could be "Wait for sources:", with push, merge_request_event, external selected by default.
  • If "Wait for external CI" is selected, and no pipeline is present for the latest commit, the mergeability check should fail
  • Otherwise, if no pipeline has been created for the latest commit, but the config has been processed, then the mergeability check should pass.

Testing Consideration

Integration Test

Write up tests for the 3 scenarios here to spec/features/merge_request/user_merges_when_pipeline_succeeds_spec.rb.

  1. When pipeline configuration exists but a pipeline didn't run for the MR, able to merge.
  2. When no pipeline configuration exists for the project, able to merge.
  3. When pipeline configuration exists and a pipeline ran, unable to merge.

Summary

The "Troubleshooting CI/CD" page says, in the "Checking pipeline status" section:

This message is shown when the merge request has no pipeline associated with the latest commit yet. This might be because:

  • GitLab hasn't finished creating the pipeline yet.
  • You are using an external CI service and GitLab hasn't heard back from the service yet.
  • You are not using CI/CD pipelines in your project.
  • The latest pipeline was deleted (this is a known issue).

For the first case, it should say something such as "Waiting to create the pipeline" to indicate that the user needs to wait for GitLab to create the pipeline. If more information, such as, if the attempt to create the pipeline is stuck in a queue, is available, it should report that (and the queue position, if that's available - "there are 4 callers ahead of you").

For the second case, it should say something to indicate that it's waiting for some external CI service to respond - and indicate what service that is, if that makes sense.

For the third case, is there even a pipeline status to check? If not, it shouldn't be trying to check it.

The fourth case appears, from what I read of the issue, to be a known bug.

Steps to reproduce

Take a look at either this Wireshark merge request or this other Wireshark merge request which, at least as of 2020-09-09 09:07:05 UTC, have the spinning "Checking pipeline status". At least as of now, some jobs started about 15 minutes ago, and those merge requests were submitted before that, so at least some some jobs are getting run for Wireshark.

What is the current bug behavior?

A spinning "Checking pipeline status" with no indication of what's wrong, when the check will finish, or what I can do, if anything, to fix it.

What is the expected correct behavior?

Something that indicates what I should do, whether it's "fix XXX in your project" or "fix XXX in your merge request" or "be patient, you're queued up behind some other jobs" or....

Output of checks

This bug happens on GitLab.com.

Edited by Hordur Freyr Yngvason