Copilot commented on code in PR #8626:
URL: https://github.com/apache/texera/pull/8626#discussion_r4060169986
##########
.github/workflows/direct-backport-push.yml:
##########
@@ -1016,9 +1070,12 @@ jobs:
pr = (await github.rest.pulls.create({
owner, repo, base: TARGET_BRANCH, head: BRANCH,
- title, body, draft: true,
+ // A clean backport opens ready for review: nobody has code to
+ // write on it, and a draft would only suggest otherwise. It
+ // still needs its checks started -- the comment below says
how.
+ title, body, draft: !clean,
Review Comment:
On a rerun, an existing open PR bypasses this creation block, so the newly
computed `clean` state is never applied to its draft/readiness or instructions.
Because the branch is force-pushed from the current release tip first, a target
movement can turn a previously clean cherry-pick into one containing conflict
markers while the existing PR remains ready for review and still says it is
clean. Update the existing PR to match the recomputed state, or fail closed
when that state changes.
##########
.github/workflows/direct-backport-push.yml:
##########
@@ -314,11 +314,23 @@ jobs:
`PR #${pullRequest.number}: push=[${push.join(", ")}]
pr=[${pr.join(", ")}]`
);
+ // Both outcomes open a pull request. Pushing a cherry-pick
+ // straight onto a release branch is rejected by the Merge Queue
+ // ruleset that covers them (#8377), and ASF policy asks for
prior
+ // Infrastructure authorization before an automated service
writes
+ // a branch subject to official release -- so a backport travels
+ // the way every other change to a release branch travels.
Review Comment:
This rerouting leaves the repository's backport documentation contradictory:
the nearby `push_entries`/`pr_entries` comments at lines 276–279 still describe
direct pushes versus draft PRs, `.github/release-branches.yml:26-29` says green
preflights push directly, and `.github/scripts/create-backport-branch.sh:19-24`
says that helper is only for red preflights. Update these descriptions with the
behavior change so future maintenance does not rely on the now-unreachable fast
path.
##########
.github/workflows/direct-backport-push.yml:
##########
@@ -1044,7 +1101,10 @@ jobs:
} catch (e) {
core.warning(`Could not fetch PR #${prNumber} author:
${e.message}`);
}
- if (author) {
+ // Only a backport somebody has to finish gets assigned. A clean
+ // one is the release manager's to review, and assigning its author
+ // would tell them they have work they do not have.
+ if (author && !clean) {
Review Comment:
A clean backport whose source author is also the release manager now gets
neither an assignee here nor a review request, because the following `MANAGER
!== author` guard still treats the source author as if they authored this
bot-owned PR. GitHub permits that manager to review the bot PR, so request them
for every clean backport to avoid leaving the required reviewer unnotified.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
