Fix: edge-case in gitlab_client

[jukie]

Closes #2484
If 2 GitLab Merge Requests reference the same commit Gitlab doesn't separate the associated pipeline runs so in that case whatever MR/branch was pushed or opened second will have an empty mr.HeadPipeline. In this case Atlantis should lookup associated pipelines and their status by using the commit sha.

Reproduction Steps (Copied from issue)

1. Checkout repo and default branch. I'll be using "main" in this example.
2. Checkout new branch: git checkout -b coolStuffA
3. Make a terraform change and commit
4. Push branch and open Merge Request for main
5. Run atlantis plan
6. Close Merge Request
7. On local you should still have coolStuffA checked out. From here create a new branch: git checkout -b coolStuffB
8. Push branch coolStuffB without any new changes: git push origin HEAD
9. Open merge request for coolStuffB into main
10. Run atlantis plan
11. Run atlantis apply - this should produce runtime error: invalid memory address or nil pointer dereference

[jukie]

@jamengual could you please review when you get a chance? This probably isn't very elegant and I'd like some input on: https://github.com/runatlantis/atlantis/pull/2495/files#diff-22d1bafb2e6e476aabe2f33484daa3f74932c6e0266f0830d7d948b8b9f60183R236-R243

[jukie]

Wondering if there's a better way to navigate to a common HeadPipeline

[jukie]

Anything I can do to help move things along?

[jamengual]

@jukie Sorry we have been away/sick/busy we will try to review it soon.

[michelmzs]

Hi @jukie, I was unable to reproduce this behavior locally.
Are you trying to merge newBranchB into newBranchA ?

[jukie]

@michelmzs no this would be mering branchB into the mainline branch and I can say it's still happening with latest version of Atlantis and Gitlab version 15.2.2

To elaborate on the steps (will update above as well):

1. Checkout repo and default branch. I'll be using "main" in this example.
2. Checkout new branch: git checkout -b coolStuffA
3. Make a terraform change and commit
4. Push branch and open Merge Request for main
5. Run atlantis plan
6. Close Merge Request
7. On local you should still have coolStuffA checked out. From here create a new branch: git checkout -b coolStuffB
8. Push branch coolStuffB without any new changes: git push origin HEAD
9. Open merge request for coolStuffB into main
10. Run atlantis plan
11. Run atlantis apply - this should produce the runtime error

[michelmzs]

Followed the exactly steps above, and still couldn't reproduce (GitLab 14.9.x, I'll try in 15.2.2).
In the GitLab 14.x the coolStuffB branch generates a new pipeline ID as the coolStuffA, so the Atlantis workflow runs normally.

[jukie]

Interesting, I hadn't realized that was a new layout in 15.x. I'll also look at whether this is unintended behavior that could be fixed in later 15.x versions or a possible bug in Gitlab vs here.

[jukie]

@michelmzs I've confirmed this again locally and against the publicly hosted gitlab.com here: https://gitlab.com/Jukie/tf-demo/-/merge_requests/3#note_1130657254
This is with the latest stable release version of Atlantis and pre-release v0.20.1

[jukie]

@michelmzs any updates here? It's a confirmed issue with 15.x but I'm unclear whether it's something that should be resolved here or in Gitlab

[michelmzs]

Sorry for late reply @jukie, I haven't tested it locally yet. On the changes, instead of looking for the parent pipeline, maybe we should address the job status update during the plan phase in the current merge request. I don't believe that issuing a plan status for another merge request than the current one is a good fit.

[michelmzs]

@jukie please have a look #2636

[nitrocode]

Thank you @jukie and @michelmzs

Looks like this PR can be closed since #2636 was merged.