Avoid coverage upload for merge up pull requests #11736
Merged
Conversation
This file contains 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
When there are no conflicts between branches, we create pull requests where the head branch is a branch on the origin repository. That branch points to a commit that should already have coverage information provided by the build that happens after merging a regular pull request. The thing is, coverage information provided by builds that happen before merging a pull request are associated with the commit of the head repository. This means that when merging up 1.2 into 1.3, the build produces coverage information that is the result of a merge between 1.2 and 1.3, and associates it with 1.2, although it is run on with a codebase that is much closer to 1.3 (and is in fact supposed to become 1.3 after the merge). This means that when we create a merge up PR from 1.2 to anything else, the coverage information is going to be wrong until a PR targeting 1.2 gets merged. I do not think we need coverage about conflictless merge up PRs more than we need accurate numbers, so I propose we disable the upload for those instead of, say, trying to associate them with the temporary merge commit.
|
Since the last merge up, there has been movement on 2.20.x, this is why the coverage is accurate. I wanted to illustrate the issue by creating a merge up PR, but since the changes in that PR do not touch |
SenseException
approved these changes
Nov 27, 2024
morozov
approved these changes
Nov 28, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When there are no conflicts between branches, we create pull requests where the head branch is a branch on the origin repository. That branch points to a commit that should already have coverage information provided by the build that happens after merging a regular pull request.
The thing is, coverage information provided by builds that happen before merging a pull request are associated with the commit of the head repository. This means that when merging up 1.2 into 1.3, the build produces coverage information that is the result of a merge between 1.2 and 1.3, and associates it with 1.2, although it is run on with a codebase that is much closer to 1.3 (and is in fact supposed to become 1.3 after the merge).
This means that when we create a merge up PR from 1.2 to anything else, the coverage information is going to be wrong until a PR targeting 1.2 gets merged.
All commits pushed during the wrong interval get such a warning on Codecov:
I do not think we need coverage about conflictless merge up PRs more than we need accurate numbers, so I propose we disable the upload for those instead of, say, trying to associate them with the temporary merge commit.