-
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
Azure DevOps branch protection status #880
Comments
@mcdafydd does this sound right? |
I'll try and dig into this a bit as soon as I can. I should have time tonight or tomorrow afternoon. Thanks for the report! |
Hi All, I went through the documentation about the Azure Devops Pull Request Status API and have started adding a new API call to It looks straightforward to fix the issue, but I'd like to get some feedback about whether we should always post the pull request status to each "iteration", or only when necessary. This is from the relevant section in the docs:
At the very least, it looks like the Reset status whenever there are new changes feature will limit this functionality to posting on iterations. I'll start by working on a PR this weekend to always add the |
I think posting it to both (iteration and PR) makes sense. We'll have to carry that iteration ID through. |
After playing with the status API a bit, I think always posting to the iteration is probably the best approach. However, it looks like this would essentially enforce the behavior of the Reset status whenever there are new changes setting regardless of the branch protection setting for the repository. I found that if a status has been posted to both the current iteration and the pull request overall, the iteration status takes precedence. If a new commit then bumps the iteration, the pull request status then takes over because there isn't a matching status for the new iteration. If we always post to the iteration, it would prevent a potential out-of-order status issue if a new commit is posted while Atlantis is processing a plan. For example:
If we post only to the pull request, the atlantis/plan status on the pull request would show as succeeded because that was the last status received. If we instead post to the iteration, it would show as failed because that is the status tied to the current iteration. |
Awesome, thanks for all that detail. I haven't found iterationId added to any of the webhook payloads, so right now I'm thinking about getting the current iteration ID by doing a List iterations and then finding the object with the matching source commit ref to the PR webhook. I may just be overlooking something obvious I hope. Also, the "supportsIterations" flag can be set to true or false when a pull request is created:
All the PRs I'm opening in the browser seem to be set |
It doesn't look like you're missing anything. I found this was an issue that was reported to the DevOps feedback site and closed as Not a Bug. Using the pull request iterations API is the workaround that was suggested there as well. |
I'm just finishing up the tests and will get a PR submitted later today. Cheers, |
Added #886 |
Using Atlantis 0.10.2 with DevOps
In DevOps when branch protection is enabled for the target branch, the Atlantis status updates are not recognized by DevOps to fulfill the required status checks.
It looks like the status checks are currently being posted to the latest commit of the source branch of the pull request.
https://dev.azure.com/mplehmann/POC-Terraform/_apis/git/repositories/POC-Terraform/commits/fe9fb32bb9654b52b2e624d070fe0380c979ecc5/statuses?api-version=5.1
In the Branches view, this does show the status information on the branch. However, the pull request doesn't recognize this as fulfilling the branch protection requirements. It looks like the status checks instead need to be posted to the pull request API URL. If I manually post the same status information to the pull request, it does pass the branch protection requirements.
https://dev.azure.com/mplehmann/POC-Terraform/_apis/git/repositories/POC-Terraform/pullRequests/9/statuses?api-version=5.1-preview.1
The text was updated successfully, but these errors were encountered: