-
Notifications
You must be signed in to change notification settings - Fork 1.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
Make required atlantis/apply
status check work with mergeable
using --gh-allow-mergeable-bypass-apply
#2436
Make required atlantis/apply
status check work with mergeable
using --gh-allow-mergeable-bypass-apply
#2436
Conversation
server/events/vcs/github_client.go
Outdated
@@ -313,6 +347,10 @@ func (g *GithubClient) PullIsMergeable(repo models.Repo, pull models.PullRequest | |||
// hooks. Merging is allowed (green box). | |||
// See: https://github.com/octokit/octokit.net/issues/1763 | |||
if state != "clean" && state != "unstable" && state != "has_hooks" { | |||
if state == "blocked" && status && approved.IsApproved { |
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.
I think the issue here is that state will always be blocked
(assuming the pending apply status) but you can't know for certain why it is blocked (GitHub api does not specify the reason, only that it is blocked)
I'm not sure if other status and approval are the only things that would block a PR
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.
@AndreZiviani for sure - I anticipated this discussion - that's definitely the majority of the issue here - trying to disentangle what's making up that state.
Also you need to actually add the pending apply status here like I did here but keep in mind that this change will affect all VCS not only GitHub Make sure to read the comments in my initial PR, this issue, this other issue, this dicussion and my last attempt This behavior would also need to be enabled/disabled via a feature flag in order to not break existing use-cases like the ones I linked before |
@AndreZiviani can you explain a little more about the need for the pending apply status? I saw that, but didn't totally understand the need there. I'll dig into that as well, but hoping you can clarify for me. |
I assumed that you want to add a pending "atlantis/apply" status check after you run the plan, its been a while since I've looked into this but I don't think it does this by default, if thats the case then you would need to do what I said earlier (this PR as is only does half of the work) |
I think I'm still missing something here - I've built this code, and when I run |
I'm sorry @AndreZiviani I'm still not understanding. When I grab atlantis@master, and then compare it to my PR, the results appear identical to me, which is what I was going for. When I run This seems correct to me - the plan is done and successful, and the apply hasn't run yet, but is expected. I wouldn't expect to see a pending apply at this point - because I haven't done anything with the apply stage. When I run This also seems correct to me, and it's the same behavior as with atlantis@master. |
Then I apologize for the confusion, I misunderstood what you are trying to do. LGTM |
I think this will have the same issue as #2311, won't it? Meaning approvals by people not in the CODEOWNER file will be allowed to apply. It might be the case I'm misunderstanding the issue in #2112, the code here, or even github's apis, but I think to support the use case of requiring CODEWONER approval we need github's pullrequest graphql object with reviewDecision field. |
You are absolutely right @chicocvenancio , that’s the main reason why I gave up trying to implement something like this |
Adding more context to the above discussion regarding As pointed out in #2112 (comment) and its following discussion, we might need to use the |
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.
+1 on the comment from @AndreZiviani A feature flag might buy us some time to polish the feature without having to revert it immediately due to potential regression.
This behavior would also need to be enabled/disabled via a feature flag in order to not break existing use-cases like the ones I linked before
@lilincmu Added a new GetPullReviewDecision function which calls the graphql api - this indeed takes into account CODEOWENRS and correctly returns "REVIEW_REQUIRED" when a CODEOWNER has not approved the request but someone else has. Is there an example of featureflag functionality being used already that I could leverage while staying aligned with the codebase? |
@jamengual it doesnt look like atlantis passes userConfig down to NewGithubClient. I could definitely add that in, might be worth adding in the entire userConfig to allow additional flags to modify how that works in the future? Is there another way to do this? |
Do we still need the feature flag with the current PR? Seems to me this should just work as is currently documented. |
It's a good question. I'm a 1st time contributor and thus looking for guidance from more seasoned contribs. No issue with feature flag rollout to minimize disruptions/accidentally introducing something else - in particular because mergeable is a meta/rollup status - I'm a little concerned we're missing something else other than just approval. As far as the feature flag though - just not totally sure how to introduce that without having to change a major func/method signature. |
server/events/vcs/github_client.go
Outdated
} | ||
|
||
//compile for performance reasons | ||
matcher, _ := regexp.Compile("atlantis/apply") |
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.
We have to pass vcsstatusname
down here since it's actually configurable. See the counterpart of GitLab as an example.
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.
Forgot about that - will fix.
server/events/vcs/github_client.go
Outdated
|
||
for _, r := range status.Statuses { | ||
if !matcher.MatchString(*r.Context) { | ||
if *r.State == "failure" { |
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.
Do we need to return false
when checks are pending
?
@rayterrill Alternatively, you might add the new flag in
@chicocvenancio Ideally we don't, however, given the history of the multiple attempts for this feature, I think we can be a bit pessimistic on it. |
Tracking another issue - looks like a previous PR attempt ran into issues with Github Actions-based checks. I added one to a test PR, and indeed, the CombinedStatus API doesn't appear to take this into account - those get reported under CheckSuite/CheckRun apis. I'll look at getting that added as well, and update the GetCombinedStatus API to handle both. |
Added additional logic to suss out only the required check runs and ignore non-required, added server config doc. |
@lilincmu do you know if there's a next step to get a maintainer to unlock the additional workflows? |
Anything else needed to move this along? |
we will merge it now and release it on the prerelease @rayterrill |
Wow thank you @jamengual ❤️ ! |
Nice job @rayterrill ! For anyone else who finds this PR from the 0.19.9 release page, remember to set one of these to allow setting atlantis/apply as a requirement. The following is documented by @chroju in PR #2568.
or flag
|
Just wanted to mention that the name for the environment variable is |
|
@rayterrill @briancurt @minamijoyo apologies for the incorrect env var. I found out the hard way as well. Please make sure to use the correct input. The docs have the correct input flag and name now. |
does the user used to run atlantis needs extra permissions in the repository to be able to check if atlantis/apply is part of the required checks? |
@Yasmine92 Yes to use the feature the Atlantis GH user needs more permissions |
// GetCombinedStatusMinusApply checks Statuses for PR, excluding atlantis apply. Returns true if all other statuses are not in failure. | ||
func (g *GithubClient) GetCombinedStatusMinusApply(repo models.Repo, pull *github.PullRequest, vcstatusname string) (bool, error) { | ||
//check combined status api | ||
status, _, err := g.client.Repositories.GetCombinedStatus(g.ctx, repo.Owner, repo.Name, *pull.Head.Ref, nil) |
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.
I think this might be #2601 - here the repo.Owner and repo.Name come from the PR Destination repository, and the pull.Head.Ref
may be the branch name in the Fork (Source repository)
From https://docs.github.com/en/rest/commits/statuses#get-the-combined-status-for-a-specific-reference it's not clear how to do this for commits on a fork.
…antis#2436) * Make required apply work with mergeable * Fix lint hint * Migrate mergeable approval check to graphql, update tests * Adding support for check suites * Adding feature flag protection for new functionality * Fix linting falsepos * Adjusted logic to handle required check runs, added doc
atlantis/apply
status check work with mergeable
using --gh-allow-mergeable-bypass-apply
Building on the work of @AndreZiviani, @nishkrishnan, and probably many others - another attempt to try to get mergeable working with required "atlantis/apply" status checks.
First contribution attempt for Atlantis 🙏 - we use this tool heavily and would love to contribute back and get this working if possible - it's a critical pain point in our workflow (and seems similar for others) - would love to partner up with a more experience Atlantis contrib to work through any issues, concerns, etc.
Tests passing locally (via
make test
).