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
This may not be a valid case, but noticed while testing an Atlantis installation:
I have a main branch where Atlantis is integrated, which plans successfully, no applies run yet.
Created a duplicate branch from this branch and created a PR - atlantis unlock was run on the initial branch.
When running plans on the duplicate branch (by duplicate I mean the same commits), both branches report the same status checks at the bottom:
so when I forgot to atlantis unlock the original PR, both branches reported failures
when I successfully plan on the second PR, both branches report a success
I am wondering if this is because of how status checks are reported? Is it based on the latest commit ID?
I have only noticed this happening since the individual "plan" status checks for each workspace / project were added, unsure if it was occurring before.
Also note this is during an Atlantis installation, so I am modifying every workspace in my repo.
This installation is a Kubernetes statefulset
Looking on the Atlantis pod, I can see the initial PR's workspaces have all been deleted after the unlock, leaving only the "default"
Reproduction Steps
Create a branch, run some atlantis plans
Create a second branch from the first (pointing to the same "source" branch, in my case main)
Run atlantis plan
Both branches should report the status from the second branch
Logs
Logs look like standard plan and apply logs, there is the commit ID mentioned when doing pulls and plans.
Environment details
Kubernetes version: v1.21
Running a statefulset with a lot of environment variables
Unsure @jamengual - we are still using the nightly build created by this PR: #2180
So haven't got any new features.
We require parallel plans to support workspaces with the same name aka <product>-<region_code> and need that change in before we can upgrade.
Community Note
Overview of the Issue
This may not be a valid case, but noticed while testing an Atlantis installation:
atlantis unlock
was run on the initial branch.When running plans on the duplicate branch (by duplicate I mean the same commits), both branches report the same status checks at the bottom:
atlantis unlock
the original PR, both branches reported failuresI am wondering if this is because of how status checks are reported? Is it based on the latest commit ID?
I have only noticed this happening since the individual "plan" status checks for each workspace / project were added, unsure if it was occurring before.
Also note this is during an Atlantis installation, so I am modifying every workspace in my repo.
This installation is a Kubernetes statefulset
Looking on the Atlantis pod, I can see the initial PR's workspaces have all been deleted after the unlock, leaving only the "default"
Reproduction Steps
atlantis plans
main
)atlantis plan
Logs
Logs look like standard plan and apply logs, there is the commit ID mentioned when doing pulls and plans.
Environment details
Kubernetes version:
v1.21
Running a statefulset with a lot of environment variables
Atlantis version:
latest
/v0.19.2
Repo Config:
Additional Context
Both PR's showing identical status checks while planning
The text was updated successfully, but these errors were encountered: