Since of today Merge Requests can’t sense changes in the source branch and stays indefinitely “Checking pipeline status”, despite the source branch has 2 commits.
It is a private project hosted on Gitlab.com.
I already tried these, but no success:
- Creation of 1 extra commit to check if it changes anything, but nothing happened. The Merge Request is still checking pipeline status for about 15 minutes, so far.
- Deletion and recreation of Merge Request.
Same issues here, also error with pipelines and local runners registration.
I’m seeing similar problems in some other repositories where contributors are adding new commits but the pipelines aren’t triggering against the branches. The commits are appearing as expected in the forks, but the MR isn’t registering new commits, and new pipelines are not being automatically triggered as expected in GitLab CI.
The first job shows that it is waiting on dependent jobs, even though it is the first job.
So we are experiencing issues impacting CI/CD and MRs.
GitLab Status has updated to show related incident:
I think that is not the right thread to get a proper answer (or suggestion) for your question. But, I hope my answer down below can give you a useful way. In case it doesn’t help you, I recommend you to open a new thread detailing your issue.
I like the way Gitlab MR keeps all possible trackings a merge request gets until it’s finished (merged). Even if you go back, like resetting or rebasing your branch, Gitlab MR is gonna keep the tracking of all old changes in your branch (old branches, actually), not only the last path (branch) until it is finished - remember that rebasing or any other ways you use to step back in the current branch actually creates a new branch (ok resetting is an exception but not for MR story), and all old ones are gonna be preserved by Gitlab.
So, as I know it doesn’t matter what you do to go back in your branch, rebasing, resetting, whatever, all old paths are gonna be preserved in the MR. But, that is great! You can recover everything you did without relying on your local git repo, since you have pushed it once to the server as a WIP (work in progress).
Check out that sample: Base project structure (!1) · Merge requests · labaz / test-gitlab-mr-story · GitLab
Look at the activity (story) that there were lots of commits (from different branches), because it was rebased and resetted. However, in the commits page there are only the last branch commits when it was merged: Base project structure (!1) · Merge requests · labaz / test-gitlab-mr-story · GitLab
The story in the activities preserves all commits even if you get a new path stepping back with a reset or rebasing the original path (branch). The best way to step back is up to you, or determined by the project maintainer, they might prefer to have in the project story the “step back” merging the current code with a old one meaning reversion, as an example, because it will appear in the project story (main branch).