-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: In Gitlab, if an Atlantis 'Apply' Pipeline Job fails, it cannot be Re-Applied on the Same Commit #4007
Conversation
I was personally unable to reproduce this issue, since for me the detailed merge status was |
That means that you still had a pipeline running, either a Gitlab or external one. |
Before and after I ran |
If you have a failed |
Here's what I'm seeing. I have set
As far as I can tell, there's no way for status to be Again, this is just what I'm seeing, and I have no issue with this change going in, since I think it's "more correct" than what we have now. I was just curious if this differs from what you're seeing, and potentially concerned this might not fix your problem. |
Why are you doing steps 4 and 5? That is not the scenario that this change is fixing. Just try running apply again at step 4. |
I tried again without 4 and 5 and got the same result. Here's my thought process:
The evidence I have for this is, when I print out the value of Two possibilities I can imagine:
|
Are you actually running this with a real failure in the apply? If so you would see that the |
I'm simulating an apply failure like this:
While the apply is running I see the |
How many states are you affecting in one MR? Please try more than one and remove the |
Setting aside my inability to reproduce the issue, can you explain what's wrong about my thought process here: #4007 (comment) For example, maybe 1) is wrong and |
Because you aren't considering the one to many directory specific |
OK I think the place where we fundamentally disagree is that, I believe that, regardless of any of the directory pipelines, during execution of the atlantis apply (and hence where this code executes), To clarify, I'm happy to get to the bottom the differences here, but in my mind it doesn't need to block this PR. Just because I don't see how we can get into a state where this is needed doesn't mean we can't, and again the logic would be more correct given this change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you both for the professional and thoughtful discussion. I will merge and we can always revert in a patch release if needed.
…be Re-Applied on the Same Commit (runatlantis#4007) * Fix GitLab CI Must Pass * Fix projectID * nolint:staticcheck * nolint:gosec * Fix formatting --------- Co-authored-by: PePe Amengual <[email protected]> Co-authored-by: Dylan Page <[email protected]>
…be Re-Applied on the Same Commit (runatlantis#4007) * Fix GitLab CI Must Pass * Fix projectID * nolint:staticcheck * nolint:gosec * Fix formatting --------- Co-authored-by: PePe Amengual <[email protected]> Co-authored-by: Dylan Page <[email protected]>
what
Update the GitLab client
PullIisMergeable
function to returntrue
ifmr.DetailedMergeStatus
isci_must_pass
.The function already individually checks all the commit statuses, and will return
false
if any other status other than Atlantis Apply statuses do not have a status ofsuccess
, so allowing this status will not stop other non-Atlantis failed CI checks from preventing an Atlantis apply.why
Fixes #3999
tests
Tested locally and Gitlab Client unit tests updated.