You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.
Overview of the Issue
We noticed an unexpected automerge in one of our pull requests that involve an individual project apply that was long running. Atlantis automerged the PR even though there are still unapplied plans. I believe the root cause of this is how the pull status is being updated in BoltDB.
Reproduction Steps
This issue can be difficult to reproduce as it requires an apply to run long:
Open a pull request with a diff that generates plans for more than one workspace.
Apply any single workspace with: atlantis apply -p <project_name>
Push a commit to trigger another autoplan
Autoplan finishes with new plan results
Apply finishes and the PR is automerged with 1/1 plans applied
Logs
When the apply finishes, it updates the commit status for the previous commit, example:
Environment details
Atlantis version: v0.19.7
If not running the latest Atlantis version have you tried to reproduce this issue on the latest version: No
If currStatus.Pull.HeadCommit != pull.HeadCommit we end up overwriting the Pull Status with the results from this apply. The problem here is that Atlantis is trying to overwrite the newer status even for applies that are targeted with -p. For individual project applies, we should still merge our project results with the existing ones even if the commit is out-of-date like we do later in the code:
Community Note
Overview of the Issue
We noticed an unexpected automerge in one of our pull requests that involve an individual project apply that was long running. Atlantis automerged the PR even though there are still unapplied plans. I believe the root cause of this is how the pull status is being updated in BoltDB.
Reproduction Steps
This issue can be difficult to reproduce as it requires an apply to run long:
atlantis apply -p <project_name>
1/1 plans applied
Logs
When the apply finishes, it updates the commit status for the previous commit, example:
Environment details
Atlantis server-side config file:
Repo
atlantis.yaml
file:Additional Context
I did some digging and this seems to stem from how Atlantis is updating the Pull Status when our pull is out of date:
atlantis/server/core/db/boltdb.go
Lines 332 to 340 in 9ab3fd2
If
currStatus.Pull.HeadCommit != pull.HeadCommit
we end up overwriting the Pull Status with the results from this apply. The problem here is that Atlantis is trying to overwrite the newer status even for applies that are targeted with -p. For individual project applies, we should still merge our project results with the existing ones even if the commit is out-of-date like we do later in the code:atlantis/server/core/db/boltdb.go
Lines 341 to 371 in 9ab3fd2
The text was updated successfully, but these errors were encountered: