Files
cozystack/hack
Myasnikov Daniil c5af8617bb fix(ci): stop an empty commit from losing a whole backport
korthout/backport-action cherry-picks a merged PR's commits one at a
time and reads any non-zero exit as a conflict: on exit 1 it commits the
working tree as BACKPORT-CONFLICT and opens a draft PR for manual fixup.
An empty cherry-pick also exits 1, but leaves nothing to commit, so the
action's own `git commit` exits 1 in turn, it aborts the whole
cherry-pick and throws. The commits it had already applied are
discarded, no branch is pushed and no PR is opened -- the original PR
gets "Backport failed ... unable to cherry-pick the commit(s)" and the
fix never reaches the release line.

So a single `git commit --allow-empty`, the usual way to re-trigger CI,
was enough to lose an entire backport, reported as a merge conflict that
does not exist. A commit whose change the target branch already carries
did the same thing.

hack/backport-git-shim.sh is installed as `git` ahead of the real one on
PATH for the backport job's own duration. It adds `--allow-empty
--empty=drop` to `git cherry-pick` and passes everything else through,
including the sequencer verbs, which `--empty` refuses to be combined
with. Measured on git 2.55, cherry-picking one commit onto a branch:

  flags                       originally empty  already upstream  conflicting
  (none)                      exit 1, lost      exit 1, lost      exit 1
  --allow-empty               carried over      exit 1, lost      exit 1
  --empty=drop                exit 1, lost      dropped           exit 1
  --allow-empty --empty=drop  carried over      dropped           exit 1

The last column is what keeps it safe: a real conflict still exits 1
with unmerged paths, so the draft-PR path is untouched and only the two
cases that used to be misreported as conflicts change.

PATH is the only injection point available. Neither the pinned action
nor upstream v4 accepts cherry-pick flags, and git has no config knob
for either behaviour. The install step drives the wrapper against a
throwaway repository before the action depends on it, because both ways
this wiring can break -- a git without `--empty`, a wrapper that cannot
resolve the real one -- otherwise surface as a failed backport on
somebody's merged PR, which is the failure being removed.

hack/backport-git-shim.bats covers the behaviour, including the
unwrapped case, so the day upstream fixes this the suite says so instead
of passing for a reason that no longer holds.

Assisted-By: LLM
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
2026-09-03 11:55:57 +05:00
..
2026-02-17 22:54:12 +01:00