[chore] Merge freeze check uses title to find Release PRs #11936
Conversation
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
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #11936 +/- ##
=======================================
Coverage 91.59% 91.59%
=======================================
Files 448 448
Lines 23759 23761 +2
=======================================
+ Hits 21761 21763 +2
Misses 1623 1623
Partials 375 375 ☔ View full report in Codecov by Sentry. |
mx-psi
reviewed
Dec 17, 2024
jade-guiton-dd
changed the title
mx-psi
approved these changes
Dec 17, 2024
codeboten
approved these changes
Dec 17, 2024
This was referenced Dec 18, 2024
Closed
mx-psi
added a commit
to open-telemetry/opentelemetry-collector-contrib
that referenced
this pull request
Jan 15, 2025
#### Description As stated in the [Release Procedure document](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/release.md#releasing-opentelemetry-collector-contrib), all merging in Contrib should be halted while the "Prepare release" PR is open. This PR adds a CI check which fails if such a release PR is currently open. This is the same as the CI check introduced in Core as part of [this issue](open-telemetry/opentelemetry-collector#11707) ([Initial PR](open-telemetry/opentelemetry-collector#11744), [bug](open-telemetry/opentelemetry-collector#11808), [fix](open-telemetry/opentelemetry-collector#11849), [bug 2](open-telemetry/opentelemetry-collector#11906), [fix 2](open-telemetry/opentelemetry-collector#11936), [fix 3](open-telemetry/opentelemetry-collector#12045), [fix 4](open-telemetry/opentelemetry-collector#12051)). Like its predecessor, this will only be fully effective once the merge queue is enabled on this repo (see #36788 for progress on that), enabling us to do proper last-minute checks instead of relying on the freeze status at the time of the latest PR update. Similarly, for proper enforcement, this check will need to be marked as required in the main branch protections (I will create an issue on the community repo to that effect once this PR is merged). #### Link to tracking issue Updates #36848 #### Testing Considering the multiple iterations this code went through on Core, it should now work properly without adaptation. However, considering the multiple iterations this code went through on Core, we should expect the unexpected, especially when it comes to the interaction with the merge queue, so release managers will need to be aware of this change, in case it breaks the release process. --------- Co-authored-by: Pablo Baeyens <[email protected]> Co-authored-by: Moritz Wiesinger <[email protected]>
chengchuanpeng
pushed a commit
to chengchuanpeng/opentelemetry-collector-contrib
that referenced
this pull request
Jan 26, 2025
…emetry#37097) #### Description As stated in the [Release Procedure document](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/release.md#releasing-opentelemetry-collector-contrib), all merging in Contrib should be halted while the "Prepare release" PR is open. This PR adds a CI check which fails if such a release PR is currently open. This is the same as the CI check introduced in Core as part of [this issue](open-telemetry/opentelemetry-collector#11707) ([Initial PR](open-telemetry/opentelemetry-collector#11744), [bug](open-telemetry/opentelemetry-collector#11808), [fix](open-telemetry/opentelemetry-collector#11849), [bug 2](open-telemetry/opentelemetry-collector#11906), [fix 2](open-telemetry/opentelemetry-collector#11936), [fix 3](open-telemetry/opentelemetry-collector#12045), [fix 4](open-telemetry/opentelemetry-collector#12051)). Like its predecessor, this will only be fully effective once the merge queue is enabled on this repo (see open-telemetry#36788 for progress on that), enabling us to do proper last-minute checks instead of relying on the freeze status at the time of the latest PR update. Similarly, for proper enforcement, this check will need to be marked as required in the main branch protections (I will create an issue on the community repo to that effect once this PR is merged). #### Link to tracking issue Updates open-telemetry#36848 #### Testing Considering the multiple iterations this code went through on Core, it should now work properly without adaptation. However, considering the multiple iterations this code went through on Core, we should expect the unexpected, especially when it comes to the interaction with the merge queue, so release managers will need to be aware of this change, in case it breaks the release process. --------- Co-authored-by: Pablo Baeyens <[email protected]> Co-authored-by: Moritz Wiesinger <[email protected]>
zeck-ops
pushed a commit
to zeck-ops/opentelemetry-collector-contrib
that referenced
this pull request
Apr 23, 2025
…emetry#37097) #### Description As stated in the [Release Procedure document](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/release.md#releasing-opentelemetry-collector-contrib), all merging in Contrib should be halted while the "Prepare release" PR is open. This PR adds a CI check which fails if such a release PR is currently open. This is the same as the CI check introduced in Core as part of [this issue](open-telemetry/opentelemetry-collector#11707) ([Initial PR](open-telemetry/opentelemetry-collector#11744), [bug](open-telemetry/opentelemetry-collector#11808), [fix](open-telemetry/opentelemetry-collector#11849), [bug 2](open-telemetry/opentelemetry-collector#11906), [fix 2](open-telemetry/opentelemetry-collector#11936), [fix 3](open-telemetry/opentelemetry-collector#12045), [fix 4](open-telemetry/opentelemetry-collector#12051)). Like its predecessor, this will only be fully effective once the merge queue is enabled on this repo (see open-telemetry#36788 for progress on that), enabling us to do proper last-minute checks instead of relying on the freeze status at the time of the latest PR update. Similarly, for proper enforcement, this check will need to be marked as required in the main branch protections (I will create an issue on the community repo to that effect once this PR is merged). #### Link to tracking issue Updates open-telemetry#36848 #### Testing Considering the multiple iterations this code went through on Core, it should now work properly without adaptation. However, considering the multiple iterations this code went through on Core, we should expect the unexpected, especially when it comes to the interaction with the merge queue, so release managers will need to be aware of this change, in case it breaks the release process. --------- Co-authored-by: Pablo Baeyens <[email protected]> Co-authored-by: Moritz Wiesinger <[email protected]>
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.
Description
The last attempt at making the Merge freeze check work in release PRs failed (#11906). This PR tries a different approach: it changes the criteria of the Merge freeze check, so that a freeze is enacted iff there is an open PR authored by @opentelemetrybot whose title contains "[chore] Prepare release" (note that if it weren't for the author, this PR would qualify).
This PR additionally reverts #11849, so no label is added to the release PR. I also added the
pull_request.enqueuedtrigger, taking inspiration from Merge Freeze, to see if it could help reject PRs earlier.I tried to make sure the freeze check would be properly skipped for the release PR itself, both in PR checks and in the merge queue, but given the state of Github's documentation, I'm not very confident about this.
Notably, these is an edge case where I'm not sure what would happen: what if another PR gets added to the merge queue at the same time as the release PR? How many times would the "merge_group" check run, and with what values for "github.event.merge_group.head_commit"? Would both PR be booted out of the queue (not great)? Would both be accepted (way worse)? Does it depend on the order?
Link to tracking issue
Fixes #11906 and fixed #11808
Testing
As always with this, it's pretty much impossible to test before merging. Once merged, I strongly recommend we do the following test to make sure that this issue does not block the real release process again:
This unfortunately does not test whether the release PR gets merged properly, but I don't see how to test until the next release process, unfortunately.