The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-6964-5040cadf383049edf90df4195d35066379d06c4e has succeeded. Run started by GitHub user Yicong-Huang (triggered by Yicong-Huang).
Head commit for run: 0ed06c51cd3162886a702e6c8ab24185baf64ee2 / Yicong Huang <[email protected]> ci: harden backport cherry-pick against package/directory renames (#6964) ### What changes were proposed in this PR? The backport automation already uses `git cherry-pick` (a 3-way merge with rename detection), not `patch`/`git apply`, so a renamed file is normally followed to its new path automatically. But every `cherry-pick` call site invokes it **bare**, leaving three merge knobs at defaults that misbehave precisely when a **package/directory rename** lands between `main` and a `release/*` branch — producing spurious conflicts on backports that would otherwise apply cleanly. This PR wraps all backport `cherry-pick` invocations with the same three settings: ``` git -c merge.renameLimit=999999 \ -c diff.renameLimit=999999 \ -c merge.directoryRenames=true \ cherry-pick -Xrename-threshold=40% ... ``` - **`merge.renameLimit` / `diff.renameLimit`** — Git silently skips inexact rename detection once the number of unpaired added/deleted paths exceeds the limit (warning only). A package-wide rename can blow past the default, degrading renamed files to "deleted + added" so picked hunks land on paths that no longer exist. Raised so detection stays on. - **`merge.directoryRenames=true`** — the default `conflict` will not auto-place a file the backport *adds* under an old package path into the renamed directory. Backports that add files are common here (see the feature-absent guard in `create-backport-branch.sh`). - **`-Xrename-threshold=40%`** — a rename that also rewrites `package`/`import` lines can drop a small file's similarity below the 50% default and miss the rename. Applied **identically** at all three cherry-pick call sites so no stage can disagree with another over a rename: - `.github/scripts/prepare-backport-checkout.sh` — pre-merge preflight cherry-pick of the squashed range. - `.github/scripts/create-backport-branch.sh` — post-merge fallback cherry-pick that opens the draft backport PR. - `.github/workflows/direct-backport-push.yml` — post-merge green path that cherry-picks straight onto the release branch (thanks @xuang7 for catching this one). Pure configuration passthrough to the merge machinery — no control-flow change, no new dependencies. ### Any related issues, documentation, discussions? Closes #6963 ### How was this PR tested? This is a configuration-only change to two shell scripts and one workflow's shell step, with no control-flow change. Verified `bash -n` (syntax) on the edited scripts and YAML parse on the workflow. The added `-c` flags and `-Xrename-threshold` are standard, long-supported `git cherry-pick` / merge-machinery options, so behavior on the existing (no-rename) path is unchanged; the new settings only take effect when a rename is present, which is exactly the case that previously conflicted. No unit tests exist for these CI helper scripts, and the real end-to-end path (backport preflight + Direct Backport Push) exercises them on the next backport-labeled PR. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.8) --------- Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/30385538387 With regards, GitHub Actions via GitBox
