mengw15 commented on code in PR #8378:
URL: https://github.com/apache/texera/pull/8378#discussion_r3922407362
##########
.github/workflows/direct-backport-push.yml:
##########
@@ -990,9 +1024,15 @@ jobs:
pr = (await github.rest.pulls.create({
owner, repo, base: TARGET_BRANCH, head: BRANCH,
- title, body, draft: true,
+ title, body, draft: !clean,
Review Comment:
Fixed in `ba751cba5` — this was the plainest of the three: every successful
clean backport would have left a comment calling it a draft that needs manual
work because the build failed, plus a permanent red `backport/<target>` status
on main. Both now branch on `clean`: the comment says the cherry-pick was clean
and names the manager it is waiting on, and the status is green with `Backport
PR #N open, auto-merge armed`.
##########
.github/workflows/direct-backport-push.yml:
##########
@@ -831,22 +850,26 @@ jobs:
CONFLICT_FILES: ${{ steps.branch.outputs.conflict_files }}
SUBJECT: ${{ steps.branch.outputs.subject }}
FEATURE_ABSENT: ${{ steps.branch.outputs.feature_absent }}
+ CLEAN: ${{ matrix.clean }}
with:
- # Open the draft as github-actions[bot], not the PAT owner, by using
- # the default GITHUB_TOKEN. Trade-off: a GITHUB_TOKEN-opened PR does
- # not trigger pull_request CI — acceptable because this is a draft
for
- # manual conflict/build resolution, so CI fires once the human pushes
- # their fix to the branch.
+ # Opened as github-actions[bot], for both outcomes. GitHub suppresses
+ # workflow runs for anything GITHUB_TOKEN does, so a clean backport's
+ # required checks are started by the step below rather than by this
+ # creation — see the comment there.
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const {
MERGE_SHA, TARGET_BRANCH, PR_NUMBER, MANAGER,
BRANCH, VERSION, HAD_CONFLICT, CONFLICT_FILES, SUBJECT,
- FEATURE_ABSENT,
+ FEATURE_ABSENT, CLEAN,
} = process.env;
const { owner, repo } = context.repo;
const prNumber = Number(PR_NUMBER);
const hadConflict = HAD_CONFLICT === "true";
+ // Clean means the cherry-pick applied and the backported tree
built
+ // green before the merge: nothing here needs a human's hands, only
+ // the release manager's confirmation.
+ const clean = CLEAN === "true";
Review Comment:
Fixed in `ba751cba5`. `CLEAN` is the pre-merge preflight's verdict, and the
branch step cherry-picks again against the release branch as it stands now, so
the two can disagree if that branch moved in between — and the losing case is
the bad one: a tree of conflict markers opened ready for review, described as
conflict-free, with auto-merge armed on it. Now `clean = CLEAN === "true" &&
!hadConflict`, so the fresher result wins and a raced backport falls back to
the draft path.
##########
.github/workflows/direct-backport-push.yml:
##########
@@ -314,11 +314,24 @@ jobs:
`PR #${pullRequest.number}: push=[${push.join(", ")}]
pr=[${pr.join(", ")}]`
);
+ // Both outcomes now 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 requires
prior
+ // Infrastructure authorization for an automated service to push
+ // to a branch subject to official release — so the fix travels
+ // the way every other change to a release branch travels.
+ //
+ // The two are not the same PR, though: a clean cherry-pick needs
+ // nobody to touch it, so it opens ready for review with
+ // auto-merge armed and the manager's approval is the only step
+ // left. A conflicted one still opens as a draft for its author.
for (const target of push) {
- pushEntries.push({
+ prEntries.push({
pr_number: pullRequest.number,
merge_sha: commit.sha,
target,
+ manager: releaseManagers.get(target) || "",
+ clean: "true",
Review Comment:
Fixed in `ba751cba5` by restoring `max-parallel: 1` on this job, which is
what `push-backports` carried and I dropped without noticing. Preparation is
serial again: each cherry-pick is taken against the release branch as it
stands, so concurrent jobs would race their branches against each other.
Merge ordering I am deliberately leaving to the merge queue rather than
stacking the PRs or chaining the arming. Once these are pull requests the queue
is what serialises merges and revalidates each combination, and building a
second ordering mechanism on top of it would be the more fragile of the two. If
two backports for the same branch genuinely depend on each other, the later
one's cherry-pick conflicts and lands on the draft path, where a human sees it.
--
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]
