Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

GitLab Checking pipeline status - running forever

I've enabled the option - Settings/General/Merge Requests/Merge Checks - Pipelines must succeed.

Since then every merge requests automatically starts execution of the pipeline which is actually what i want. The problem is that this is running forever , i'm receiving message : Checking pipeline status If i run the pipeline manually from CI/CD Pipelines - Run pipeline finish immediately. I don't understand what is wrong and why it stuck , can i check logs somewhere or something ?

For testing , the pipeline is really simple , just exit 1 .. but still not working ..

At this stage , "running pipeline" is not listed in pipeline list even if the status in merge request is

Checking pipeline status

like image 261
Harry Birimirski Avatar asked Oct 12 '20 07:10

Harry Birimirski


People also ask

Why is my GitLab pipeline failing?

It might be a security vulnerability The code in your most recent commit could be vulnerable, or a dependency could be at risk, either of which would trigger a failed security test and thus a failed pipeline.

Why is GitLab pipeline blocked?

A pipeline may have been blocked by the pipeline validation service if an expected pipeline is not created. A pipeline might be generated via: a new push. a manual action.

Where can I find GitLab runner logs?

To view them, open the Event Viewer (from the Run menu, type eventvwr. msc or search for “Event Viewer”). Then go to Windows Logs > Application. The Source for Runner logs is gitlab-runner .

Why merge button is red in GitLab?

Its an extra manual step to check what master's pipeline status is, and the last pipeline might still be running. GitLab should check if the last pipeline that finished was actually a succcess, not a failure. If it failed, make the merge button red.

Why is my GitLab pipeline stuck on running?

In my case the pipeline was stuck because the only available runner had the option " Can run untagged jobs " set to " No " and the job was really untagged. One can fix this issue by changing the " Can run untagged jobs " option or by adding a tag to the appropriate section of the ".gitlab-ci.yml" file in the repository.

Why is GitLab not responding to my merge request?

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. You are using CI/CD pipelines in your project, but your configuration prevented a pipeline from running on the source branch for your merge request. The latest pipeline was deleted (this is a known issue).

How to check if there is no pipeline for merge request?

And I found that if there is no pipeline for the merge source branch, the headPipeline will be null which means that there is NO pipeline status to check. And onlyAllowMergeIfPipelineSucceeds being true means blocking merge request by pipeline status. But there is no such status. I go to repository “Settings” → “General” → “Merge requests”.

Why does my pipeline status show up as 'checking pipeline status'?

That will cause 'checking pipeline status' to be displayed. This could happen due to issues with sidekiq jobs (latency due to incidents or infra issues). I would agree that better messaging would likely help, in this condition. There was a suggestion here gitlab-foss#40004 (comment 46777962) that sounds good.


Video Answer


8 Answers

We ran into a case where a merge request does not contain the .gitlab-ci.yml file. The fix is simply to do a rebase

For troubleshooting purposes, pipelines can be run manually on particular branches at CI/CD -> Pipelines -> Run Pipeline

like image 111
Poh Zi How Avatar answered Oct 24 '22 03:10

Poh Zi How


For me what happened that .gitlab-ci.yml file was having issue as I have mentioned "master" as value for "only" label .. , then everything worked after updating it with my correct branch name which IMO should be "main"

like image 9
vikanksh nath Avatar answered Oct 24 '22 02:10

vikanksh nath


Encountered this myself just now, using Gitlab shared runners. Tried re-running one individual job from the pipeline in the hope that it would resolve the issue. It did not. The best way is to change the commit id of the latest change in the MR. You can either create an empty commit as suggested by @Bhargav11 or, to keep a cleaner commit history, do

$ git commit --amend --no-edit
$ git push --force

on your branch.

like image 6
milgner Avatar answered Oct 24 '22 02:10

milgner


check if current branch you are checking the pipeline status and branch specified in "only: field" are same only: - master

enter image description here

like image 4
ANANTH AYYASWAMY Avatar answered Oct 24 '22 04:10

ANANTH AYYASWAMY


Just add an empty commit to trigger it again.

git commit -n -m "commit comment"
like image 2
Bhargav Tavethiya Avatar answered Oct 24 '22 04:10

Bhargav Tavethiya


From GitLab documentation: "Checking pipeline status" message

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.

  • You are using CI/CD pipelines in your project, but your configuration prevented a pipeline from running on the source branch for your merge request.

  • The latest pipeline was deleted (this is a known issue).

like image 2
Hamza AZIZ Avatar answered Oct 24 '22 02:10

Hamza AZIZ


This happens to me with pipelines that has no job that triggers on merge-requests.

If I have no tests or anything I wish to run during a merge requests I create a "dummy" job that doesn't do anything.

Rule to trigger on merge requests:

rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

Then add a simple echo in the script section:

script: echo "Dummy job for merge-request"
like image 2
Kilathaar Avatar answered Oct 24 '22 03:10

Kilathaar


I found what was wrong in my case. The problem was with the runners. There was "Shared runners" enabled by default which caused the confusion. I've just disabled them and enable my own runner and everything started to work as expected. You can check this in CI / CD Settings, I think they are enabled by default. Basically , pipelines are nothing more than a trigger for the runner... then the runner is responsible for the execution.

like image 1
Harry Birimirski Avatar answered Oct 24 '22 04:10

Harry Birimirski