[BUILD] Fix packaging CI: ENOSPC, PR-trigger removal, tag matching, version sync#796
Open
shiptux wants to merge 8 commits into
Open
[BUILD] Fix packaging CI: ENOSPC, PR-trigger removal, tag matching, version sync#796shiptux wants to merge 8 commits into
shiptux wants to merge 8 commits into
Conversation
The full-source wheel build peaks close to the standard runner's ~14 GB free disk: two Build-RPM runs hit ENOSPC on 2026-07-15 (fedora43 during wheel zip packing, openeuler2403 during final link), blocking unrelated PRs. Packaging is a release artifact, not a PR gate: - drop the pull_request trigger; keep tag push + workflow_dispatch - reclaim ~25-30 GB by removing unused preinstalled toolchains - add a concurrency group to cancel superseded runs
Remove /src/build and /root/.triton at the end of the wheel-build RUN so the layer keeps only /wheels. The CMake build tree plus the downloaded LLVM tarballs add several GB to the layer and contribute to ENOSPC on CI runners; they are dead weight once the wheel exists.
The spec and debian changelog still said 0.5.0 while setup.py builds flagtree 0.6.0, so packages were mislabeled. Bump both to 0.6.0 and make the rpm install step fail if the wheel version ever drifts from the spec Version again.
Skip the sudo rm -rf toolchain cleanup unless RUNNER_ENVIRONMENT is github-hosted, so a future switch to a self-hosted runner cannot wipe a persistent machine.
The tag trigger only matched 'v*', but FlagTree release tags dropped the v prefix after v0.3.0 (0.6.0, 0.6.0rc1, ...), so tag pushes never started a packaging build. Match unprefixed numeric tags too, and skip backend-variant tags (0.6.0+mthreads3.6) at the job level: '+' is not a valid RPM Version character and those releases are not the nvidia package.
shiptux
requested review from
Galaxy1458,
menchunlei,
sunnycase and
zhzhcookie
as code owners
Move the rationale narrative to the PR description; keep only the constraints a reader needs at the code.
Packaging edits do need CI validation before merge, and contributors without write access cannot use workflow_dispatch upstream. Narrow the paths to packaging/** and the workflow file itself instead of the old python/**-wide filter that ran the 45-min build on unrelated PRs.
Install the freshly built rpm/deb in the assembler stage and run 'import triton'. rpmbuild/dpkg-buildpackage validate packaging metadata but never execute the payload, so the 'installs fine, fails at import' class (missing libs, bad rpath, glibc mismatch) went undetected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #794. Fixes the packaging CI issues seen this week (two Build-RPM runs hit ENOSPC on 2026-07-15 and blocked unrelated PRs).
python/**-wide filter ran the ~45-min build on unrelated PRs (e.g. an mthreads change building the nvidia package). PRs now trigger only onpackaging/**/ workflow-file changes; source-code coverage moves to release tags +workflow_dispatch.v*never matched: release tags are unprefixed since 0.3.0 (0.6.0,0.6.0rc1). Match numeric tags and skip backend-variant tags (0.6.0+mthreads3.6) at the job level.Why ENOSPC: disk breakdown of one packaging job
ubuntu-latestrunners have ~14-20 GB free (varies per machine — hence the flakiness). Peak usage per job:libtriton.so(~4-8 GB), setuptools' two full staging copies (~2-3 GB), wheel zip ×2 (365 MB each)Total peak ~13-18 GB rides exactly on the free-space line; both observed failures happened inside the wheel-build peak (fedora43 while zipping the wheel, openeuler2403 at final link). The cleanup step raises headroom past the peak; the in-layer
rmstops the dead build tree from being carried through the assembly stage.