You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Edits to amber's LICENSE-binary and NOTICE-binary files skip the CI checks that validate them #8294
.github/labeler.yml has no glob that matches amber's binary-license
manifests, so a PR that edits one gets no stack label, precheck selects
no stacks, and the build job is skipped -- including the very check that
validates the file that changed.
The aggregate Required Checks gate treats build: skipped as passing, so such
a PR goes green without running anything:
Every other module is covered because its label uses a directory-wide glob
(frontend/**, agent-service/**, access-control-service/**, ...), so
e.g. frontend/LICENSE-binary is picked up by frontend. amber/ is the
exception: it has no amber/**, and the engine / pyamber labels enumerate
specific paths instead.
Tracked files under amber/ that currently match no labeler glob:
File
Validated by
Stack that should fire
amber/LICENSE-binary-python
check_binary_deps.py python (pyamber 3.12)
pyamber
amber/LICENSE-binary-java
check_binary_deps.py jar (amber)
engine
amber/NOTICE-binary
generate_notice_binary.py regen+diff (amber)
engine
amber/NOTICE-binary-python
same, via --extras (amber)
engine
amber/DESCRIPTION
--
(unclear -- separate question)
amber/src/bench/scala/**
Benchmarks workflow
(unclear -- separate question)
This is the same hole the pyamber label's own comment already warns about one
file over:
Without this a bumped requirements.txt would only get dependencies (no stack
mapping) and silently skip CI for the very deps it's changing.
It bites in practice: #8293 fixes a repo-wide pyamber 3.12 license failure by
adding one bullet to amber/LICENSE-binary-python, and its build job was
skipped -- the pyamber label had to be applied by hand for the fix to be
tested at all. The nightly exact-match refresh of those same pins would land the
same way.
Suggested fix: add the four manifests to the globs of the label whose stack owns
their check -- amber/LICENSE-binary-python under pyamber, and amber/LICENSE-binary-java / amber/NOTICE-binary* under engine. Whether amber/DESCRIPTION and amber/src/bench/scala/** want a mapping is a separate
call.
One correction that strengthens the case: the hand-applied label does not work around this. The issue reads "the pyamber label had to be applied by hand for the fix to be tested at all" — it was applied by hand, and #8293 still ran nothing.
.github/workflows/pr-labeler.yml:31 sets sync-labels: true, so the labeler removes labels whose globs no longer match — including ones a human added:
2026-08-31T14:45:54Z labeled pyamber by aglinxinyuan
2026-08-31T16:12:10Z unlabeled pyamber by github-actions[bot]
And the sweep wins the race by design. precheck waits for the labeler to finish before reading labels — the comment at precheck.yml:201 says "Re-fetch labels: the labeler may have just added some" — so it reads the set after the sweep:
PR labels: fix, release/v1.2
Stacks selected by label union: (none)
So the sequence is:
human adds pyamber -> next pull_request event -> labeler sweeps it (no matching glob)
-> precheck waits for labeler, re-fetches -> (none) -> every stack skipped
Two consequences for the fix:
There is no operator-side workaround today. Widening the globs isn't hygiene, it's the only route — a maintainer cannot force the stack on a LICENSE-binary-only PR, and re-labelling after the sweep only holds until the next event.
--label on the PR at creation time fares no better, since the sweep happens on subsequent events.
Meanwhile #8293's one-line change is verified out-of-band: check_binary_deps.py takes --license-binary, so pointing the real checker at each side of the diff with a pip-licenses CSV built from the manifest's own 109 packages plus cloudpickle==3.1.2 gives exit=1 with the exact CI line before and OK: 110 Python packages match LICENSE-binary. after. Details in #8293 (comment). That is a workaround for one PR, not for the gap.
Activity
aglinxinyuan commentedon Aug 31, 2026
One correction that strengthens the case: the hand-applied label does not work around this. The issue reads "the
pyamberlabel had to be applied by hand for the fix to be tested at all" — it was applied by hand, and #8293 still ran nothing..github/workflows/pr-labeler.yml:31setssync-labels: true, so the labeler removes labels whose globs no longer match — including ones a human added:And the sweep wins the race by design.
precheckwaits for the labeler to finish before reading labels — the comment atprecheck.yml:201says "Re-fetch labels: the labeler may have just added some" — so it reads the set after the sweep:So the sequence is:
Two consequences for the fix:
--labelon the PR at creation time fares no better, since the sweep happens on subsequent events.Meanwhile #8293's one-line change is verified out-of-band:
check_binary_deps.pytakes--license-binary, so pointing the real checker at each side of the diff with apip-licensesCSV built from the manifest's own 109 packages pluscloudpickle==3.1.2givesexit=1with the exact CI line before andOK: 110 Python packages match LICENSE-binary.after. Details in #8293 (comment). That is a workaround for one PR, not for the gap.fix(amber): declare cloudpickle in LICENSE-binary-python (apache#8293)
anthonychengit commentedon Sep 13, 2026
/take
fix(amber): declare cloudpickle in LICENSE-binary-python (apache#8293)