chore: fix PRlinter dequeuing PRs because of CodeCov#33137
Merged
Conversation
If we don't know the result of the CodeCov results yet, we used to ask for changes, because it prevents merging while the check might still fail in the future. The following sequence of events happens because of this: 1. PR is ready to be merged (approved, everything passes) 2. Mergify enqueues it and merges from main 3. CodeCov needs to run again 4. PR linter requests changes because CodeCov result is uncertain 5. Mergify dequeues the PR because PR linter requests changes This looks very confusing and noisy, and also will never fix itself, so the PR ends up unmerged. The better solution would probably be not to do a "Request Changes" review, but leave a comment and create a GitHub "status" on the PR to say 'success/pending/failure', and make it required. (#33136) For now, not doing anything with a 'waiting' status is a smaller delta, and the race condition posed by it is unlikely to happen given that there are much slower jobs that the merge is blocked on anyway. See also #33136.
aws-cdk-automation
previously requested changes
Jan 24, 2025
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #33137 +/- ##
=======================================
Coverage 81.57% 81.57%
=======================================
Files 227 227
Lines 13793 13793
Branches 2419 2419
=======================================
Hits 11251 11251
Misses 2270 2270
Partials 272 272
Flags with carried forward coverage won't be shown. Click here to find out more.
|
mrgrain
approved these changes
Jan 24, 2025
Collaborator
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Contributor
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
iankhou
approved these changes
Jan 24, 2025
Contributor
|
Comments on closed issues and PRs are hard for our team to see. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If we don't know the result of the CodeCov results yet, we used to ask for changes, because it prevents merging while the check might still fail in the future.
The following sequence of events happens because of this:
This looks very confusing and noisy, and also will never fix itself, so the PR ends up unmerged. You can see it happening here: #33129
The better solution would probably be not to do a "Request Changes" review, but leave a comment and create a GitHub "status" on the PR to say 'success/pending/failure', and make it required. (#33136)
For now, not doing anything with a 'waiting' status is a smaller delta, and the race condition posed by it is unlikely to happen given that there are much slower jobs that the merge is blocked on anyway.
See also #33136.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license