Skip to content

fix: correct the upstream-sync workflows:write mistake — that permission key doesn't exist - #58

Merged
solderzzc merged 1 commit into
mainfrom
fix/upstream-sync-workflows-write-invalid
Aug 16, 2026
Merged

fix: correct the upstream-sync workflows:write mistake — that permission key doesn't exist#58
solderzzc merged 1 commit into
mainfrom
fix/upstream-sync-workflows-write-invalid

Conversation

@solderzzc

Copy link
Copy Markdown
Member

Summary

Corrects a mistake in #55. That PR added workflows: write to this workflow's permissions: block, on the assumption it was a grantable GITHUB_TOKEN scope — it isn't. There is no such permissions key, and GitHub's schema validator now rejects the file outright:

could not create workflow dispatch event: HTTP 422: Invalid Argument -
failed to parse workflow: (Line: 16, Col: 3): Unexpected value 'workflows'

This is strictly worse than the original bug (a silently-failing push vs. an invalid workflow file).

Real fix

GITHUB_TOKEN can never push a commit that touches .github/workflows/* — that restriction is hard-coded and isn't scoped by permissions:. The sibling mlx-swift/upstream-sync.yml already works around this correctly (and has succeeded on every run): restore .github/workflows from origin/main after merging upstream, so the push never actually contains workflow-file changes. This PR applies the same pattern here.

Test plan

  • python3 -c "import yaml; yaml.safe_load(open('.github/workflows/upstream-sync.yml'))" parses cleanly.
  • After merge, trigger workflow_dispatch and confirm it runs (no schema-parse error) and pushes successfully.

…ion key doesn't exist

The previous fix (merged as #55) added workflows: write to this file's
permissions: block on the mistaken assumption that it's a grantable
GITHUB_TOKEN scope, mirroring the wording of the push-rejection error
message. It isn't — there is no such permissions key at all, and
GitHub's schema validator now rejects this file outright (confirmed via
a failed workflow_dispatch: "Unexpected value 'workflows'"), which is
strictly worse than the original bug.

GITHUB_TOKEN can never push a commit touching .github/workflows/*,
full stop — that restriction isn't scoped by permissions: and can't be
granted to the default token. mlx-swift's sibling upstream-sync.yml
already works around this correctly: restore .github/workflows from
origin/main after merging upstream, so the push never actually touches
workflow files. This applies the same pattern here.
@solderzzc
solderzzc merged commit c01f996 into main Aug 16, 2026
7 of 8 checks passed
@solderzzc
solderzzc deleted the fix/upstream-sync-workflows-write-invalid branch August 16, 2026 16:14
solderzzc added a commit that referenced this pull request Aug 16, 2026
…59)

#58's restoration step (git checkout origin/main -- .github/workflows)
looked right but was a no-op for exactly the case that matters: a
workflow_dispatch run just failed again with the identical
integration_tests.yml rejection.

git checkout <ref> -- <path> only overwrites paths that already exist
in <ref>. It doesn't delete files present in the working tree/index
but absent from <ref> — so a brand-new file the merge just pulled in
from upstream (origin/main never had it) survives untouched, and the
push still gets rejected for it.

Verified locally with a throwaway git sandbox reproducing the exact
scenario (origin lacks a file, upstream adds it, merge, restore):
without rm -rf first, the restore step produces a zero-diff commit and
the new file is still there; with it, the file is correctly staged for
deletion and the restore actually restores.

Co-authored-by: Aegis AI Assistant <simba@aegis-ai.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant