…name cannot conflict
AMD's 2026-10-28 pin c1e1bcbf6839 renames the four HRX tests (test-hrx-buffer ->
hrx-buffer-test, test-hrx-ops -> hrx-ops-test, ...) and rewrites how they are registered in
tests/CMakeLists.txt. HRX_PATHS covers the .cpp files with 'tests/*hrx*', but the registration
block lives in one shared file that was not covered, so while hrx-system is held (the path that
replays only AMD's changes outside the HRX backend) the rename was merged into our line and the
run died on the conflict:
::error::taking AMD's c1e1bcbf6839 changes outside the HRX backend conflicts in: tests/CMakeLists.txt
That is the failure in run 40692914102 (engine#628). All 16 files in the pin delta
43b0ec2c..c1e1bcbf are HRX backend files, so with the fix the held path reports "changes only
HRX backend files (16 since 43b0ec2c)" and leaves 1bit/hrx-vulkan-patched at 40c4ccb76e48 while
moving the mirror 1bit/hrx-vulkan to AMD's pin -- exactly what the hold intends.
Also carry the reason into the warning when the fork's master cannot be refreshed: every run logs
"without `workflow` scope (HTTP 422)", and the previous message hid that the fix is a token
permission and not a fork problem. The message contains no secret.
Fixes #628.
What was failing
Scheduled run 40692914102, step Sync the fork and merge AMD's pin into our line:
Why
config/hrx-system-hold.confignames82804197bcbe, sobump-hrx-sync.shtakes the held path: it builds AMD's pin tree withHRX_PATHSreverted to the merge base and merges that into1bit/hrx-vulkan-patched. AMD's pinc1e1bcbf6839renames the four HRX tests (test-hrx-buffer->hrx-buffer-test,test-hrx-ops->hrx-ops-test, ...) and rewrites their registration intests/CMakeLists.txt.HRX_PATHScovered the test sources withtests/*hrx*, but nottests/CMakeLists.txt, where the targets are registered — so AMD's rename was carried into our line and collided with our own registration (we have ~14 extratest-hrx-*targets AMD does not).The whole pin delta is HRX backend work:
so
tests/CMakeLists.txtbelongs with the HRX test targets it registers.Before and after, same command
before (
origin/main):::error::taking AMD's c1e1bcbf6839 changes outside the HRX backend conflicts in: tests/CMakeLists.txt, exit 1after (this branch):
exit 0. The hrx-system half was skipped in the failed run, so I dry-ran it too:
scripts/bump-hrx-sync.sh hrx-> held at82804197bcbe, exit 0.With this, the nightly run reaches Open the bump PR, finds
bump-hrx/40c4ccb76e48-82804197bcbealready exists (that is #610) and exits 0 with a notice. It goes properly quiet once #610 lands.Second, non-blocking finding
The run also logs, every time:
HRX_BUMP_TOKENhas lost the Workflows: read/write permission the workflow header asks for, so the fork'smasteris never refreshed. Not fatal for the pin sync. The second commit carries that reason into the annotation instead of swallowing it — the token itself needs an owner to re-scope it.Verification
bash -n scripts/bump-hrx-sync.shghthat fails with the real 422 text: prints::warning::could not refresh 1bit-MONSTER/llama.cpp master: gh: refusing ... (HTTP 422); continuing with the HRX pin sync, exits 0Nothing else touched;
DRY_RUN=1pushes nothing.