Regression of #29301: orphan-branch first commit pushes unsigned, fails on "Require signed commits" rulesets

[mason-tim]

Summary

PR #29330 (which fixed #29301) routed push_repo_memory.cjs through pushSignedCommits so memory commits are server-signed via the GraphQL createCommitOnBranch mutation and pass Require signed commits rulesets.

PR #30463 then fixed a separate, real bug — orphan-branch first commits being silently dropped when ${baseRef}..HEAD resolves to zero shas — by adding an early-return guard in actions/setup/js/push_signed_commits.cjs. That guard does the right thing for unsigned environments, but it falls back to plain git push, which bypasses the signed-commit path:

// actions/setup/js/push_signed_commits.cjs (current main)
async function pushSignedCommits({ ..., baseRef, ... }) {
  if (!baseRef) {
    core.info(`pushSignedCommits: empty baseRef detected (orphan branch first push), using git push directly for branch ${branch}`);
    await exec.exec("git", ["push", "origin", branch], {
      cwd,
      env: { ...process.env, ...(gitAuthEnv || {}) },
    });
    ...
    return headSha;
  }
  ...
}

Result: on any repo with a Require signed commits ruleset, the first push to a brand-new memory branch fails with GH013 — the exact failure mode #29301 was filed against. Because the branch is never created on origin, every subsequent run takes the same orphan-first-commit path and fails identically. Memory never persists; agents see "first baseline" indefinitely.

Reproduction

A repository with the org-level "Commits must have verified signatures" ruleset applied to all branches, running any workflow that uses safe-outputs.repo-memory for the first time on a fresh memory id (so the memory branch does not yet exist on origin), with gh-aw v0.71.6 (or v0.72.x — same code path).

Sanitized log excerpt from the Push repo-memory changes step:

Branch memory/<id> does not exist, creating orphan branch...
Cleaning working directory for orphan branch...
Created orphan branch: memory/<id>
...
Scan complete: Found 1 file(s) to copy
Copied: metrics-history.json (3750 bytes)
Changes detected, committing and pushing...
[memory/<id> (root-commit) <sha>] Update repo memory from workflow run <run-id>
 1 file changed, 59 insertions(+)
Pushing changes to memory/<id> (attempt 1/4)...
pushSignedCommits: empty baseRef detected (orphan branch first push), using git push directly for branch memory/<id>
remote: error: GH013: Repository rule violations found for refs/heads/memory/<id>.
remote: - Commits must have verified signatures.
remote:   Found 1 violation:
remote:   <sha>
 ! [remote rejected] memory/<id> -> memory/<id> (push declined due to repository rule violations)
error: failed to push some refs to 'https://github.com/...'
##[warning]Push failed (attempt 1/4), retrying in 1000ms: The process '/usr/bin/git' failed with exit code 1
fatal: could not read Username for 'https://github.com': No such device or address
ls-remote on retry failed, keeping existing baseRef: The process '/usr/bin/git' failed with exit code 128
Pushing changes to memory/<id> (attempt 2/4)...
pushSignedCommits: empty baseRef detected (orphan branch first push), using git push directly for branch memory/<id>
... [same GH013 rejection × 4] ...
##[error]Failed to push changes after 4 attempts: The process '/usr/bin/git' failed with exit code 1

Analysis

Root cause

pushSignedCommits's orphan-branch first-push guard uses git push to create the branch, bypassing the GraphQL signed-commit path that was specifically introduced (#29330) to satisfy verified-signatures rulesets.

Design constraint to preserve

Memory branches are intentionally orphan — no shared ancestry with source. Any fix should preserve this:

• git log memory/<id> should show only memory commits, not the source history.
• A force-push or full reset of memory cannot affect source history.
• Memory data cannot accidentally be merged into main (no merge base).

So a fix that re-parents memory branches under main's HEAD (the obvious workaround) regresses an architectural property and should be rejected.

Prior art ruled out

• GraphQL createCommitOnBranch — expectedHeadOid is non-null in the schema, so the mutation cannot be called for the first commit on a branch that doesn't yet exist.
• REST PUT /repos/{owner}/{repo}/contents/{path} — auto-signs when called by a GitHub App, but requires the target branch to already exist (returns 422 otherwise). Cannot seed an orphan branch.
• REST POST /git/commits — accepts a caller-supplied signature field but does not auto-sign. The runner has no signing key.
• git push -S / git commit -S — the runner has no GPG key and shipping one with the action is a non-starter.

Open question for the maintainers

Is there a documented REST/GraphQL combination that produces a server-signed root commit on a brand-new orphan branch? If not, the design may need a different shape — for example:

(a) A one-time API-only seed step: REST create a tree (POST /git/trees), then a low-level commit (POST /git/commits with no parents), then the ref (POST /git/refs), accepting that the seed commit lands as Unverified and relying on a ruleset bypass for the seed only. Subsequent commits on the now-existing branch take the GraphQL signed path.

(b) A non-destructive "anchor" first commit on main: POST /git/refs to point memory/<id> at main's current HEAD, then immediately use GraphQL createCommitOnBranch to overwrite the tree to memory contents. The branch is no longer truly orphan (has main as ancestor), but it's signed end-to-end. (Likely rejected — regresses the orphan property.)

(c) A new server-side signing path — coordinate with the GraphQL team to expose createCommitOnBranch with expectedHeadOid: null for the brand-new-branch case. Out of scope for this repo, but the right long-term fix.

(d) Something the maintainers know about that I don't — please advise.

I'd rather not prescribe an implementation in this issue without knowing which of these (or another option) the team prefers, given that #30463 was closed less than a week ago and clearly considered the constraints carefully.

Implementation plan (once direction is agreed)

Files affected

• actions/setup/js/push_signed_commits.cjs — replace the unsigned git push in the if (!baseRef) branch with the chosen signed seed strategy.
• actions/setup/js/push_repo_memory.cjs — only if the chosen strategy needs a different baseRef value or pre-checkout flow.
• actions/setup/js/push_signed_commits.test.cjs — new tests:
  • Orphan-branch first push lands as a Verified commit (mock GraphQL/REST responses, assert the chosen endpoints are called and unsigned git push is not).
  • Orphan-branch first push retries correctly when the chosen endpoint returns a transient error.
  • Existing non-orphan signed-push tests continue to pass unchanged.
• actions/setup/js/push_repo_memory.test.cjs — end-to-end test covering "fresh memory id, ruleset-protected repo, first push succeeds".
• docs/src/content/docs/reference/repo-memory.md — note that memory commits, including the first commit on a new memory branch, are pushed as Verified and satisfy Require signed commits rulesets.

Acceptance criteria

1. On a repo with Require signed commits enforced for all branches, the first memory push of a fresh memory id succeeds and the resulting commit shows the Verified badge in the GitHub UI.
2. Memory branches retain orphan property (no shared ancestry with main) — git merge-base memory/<id> main returns no merge base.
3. The unsigned-fallback path that fix: orphan branch first push silently discarded by empty baseRef in pushSignedCommits #30463 introduced for non-ruleset repos continues to work (no regression of fix: orphan branch first push silently discarded by empty baseRef in pushSignedCommits #30463).
4. Existing test suite passes; new tests cover the orphan-signed path.

References

• repo-memory push fails with "Commits must have verified signatures" — push_repo_memory.cjs should use pushSignedCommits #29301 — original report of unsigned-commit failure on Require signed commits rulesets
• fix: repo-memory push uses GraphQL signed commits to satisfy "Require signed commits" rulesets #29330 — fix that routed memory pushes through pushSignedCommits
• fix: orphan branch first push silently discarded by empty baseRef in pushSignedCommits #30463 — orphan-branch first-commit fix (this regression)
• actions/setup/js/push_signed_commits.cjs lines 134–149 (current main)
• actions/setup/js/push_repo_memory.cjs lines 160–210 (current main)

Happy to take a stab at the PR once a direction is agreed.

[mason-tim]

Update — second compounding bug discovered

After hand-seeding the memory branch with a locally-signed commit (so baseRef is non-empty and the orphan-fallback path is bypassed), the non-orphan GraphQL path also fails for the same end-result: the unsigned git push fallback runs and the ruleset rejects it.

Symptom

Sanitized log from the next run after seeding:

[command]/usr/bin/git rev-list --parents --topo-order --reverse <seed-sha>..HEAD
<new-sha> <seed-sha>
pushSignedCommits: replaying 1 commit(s) via GraphQL createCommitOnBranch (branch: memory/<id>, repo: <owner>/<repo>)
[command]/usr/bin/git diff-tree -r --raw <new-sha>
:100644 100644 ... Makefile metrics-history.json
pushSignedCommits: processing commit 1/1 sha=<new-sha>
[command]/usr/bin/git ls-remote origin refs/heads/memory/<id>
fatal: could not read Username for 'https://github.com': No such device or address
##[warning]pushSignedCommits: GraphQL signed push failed, falling back to git push: The process '/usr/bin/git' failed with exit code 128
[command]/usr/bin/git push origin memory/<id>
remote: error: GH013: Repository rule violations found for refs/heads/memory/<id>.
remote: - Commits must have verified signatures.

Root cause

actions/setup/js/push_signed_commits.cjs line 307 (current main):

const { stdout: oidOut } = await exec.getExecOutput(
  "git",
  ["ls-remote", "origin", `refs/heads/${branch}`],
  { cwd }
);

This call does not pass gitAuthEnv in the env option, unlike the explicit git push calls on the same file (lines 142 and 386) which do. Combined with the calling push_repo_memory.cjs:

• Line 471 strips the token out of the origin URL (git remote set-url origin "https://${serverHost}/${targetRepo}.git" — no x-access-token: prefix). The comment at line 469 says this is so pushSignedCommits can resolve the remote branch HEAD via ls-remote origin and so the git-push fallback hits the right repo.
• The generated workflow's actions/checkout step in the push_repo_memory job is configured with persist-credentials: false, so the http.https://github.com/.extraheader is never set.
• The job adds its own Configure Git credentials step that writes git remote set-url origin "https://x-access-token:${GITHUB_TOKEN}@..." — but push_repo_memory.cjs line 471 then overwrites that URL back to the no-token form before pushSignedCommits runs.

Net result: git ls-remote origin has no auth → prompts for a username → fails with fatal: could not read Username → catch handler in pushSignedCommits falls back to plain git push → the same unsigned-fallback rejection as the orphan-branch case.

Why this matters

The two bugs together mean memory pushes are completely broken on repos with Require signed commits rulesets, both first-time AND ongoing — not just the first push. The seed workaround buys nothing because the ls-remote auth failure happens on every subsequent run too.

Suggested fix shape (small + targeted)

pushSignedCommits should pass gitAuthEnv to the ls-remote call the same way it does for the git push fallback. One-line change:

const { stdout: oidOut } = await exec.getExecOutput(
  "git",
  ["ls-remote", "origin", `refs/heads/${branch}`],
  { cwd, env: { ...process.env, ...(gitAuthEnv || {}) } }
);

This is independent of the orphan-branch question in the original issue and could ship separately. With this fix alone, hand-seeding the branch (one signed commit, done by the user) becomes a viable workaround until the orphan-first-commit signing question is resolved.

Test coverage to add

actions/setup/js/push_signed_commits.test.cjs:

• New test: GraphQL path with gitAuthEnv set succeeds even when actions/checkout ran with persist-credentials: false (mock ls-remote to require the env vars in gitAuthEnv and fail otherwise).
• Existing GraphQL-path tests continue to pass.

[mason-tim]

Regression trigger identified

For maintainer context: this regression appears to have been introduced by #31478 (Add codemod to enforce persist-credentials: false on actions/checkout steps), merged 2026-05-11 at 11:41 UTC. The first failing run in our environment occurred ~1 hour later after recompiling with the new codemod applied.

The chain

1. fix: repo-memory push uses GraphQL signed commits to satisfy "Require signed commits" rulesets #29330 (2026-04-30) made push_repo_memory.cjs delegate to pushSignedCommits. Its design depends on two separate auth sources:

   • The internal git ls-remote origin call relies on the http.extraheader that actions/checkout writes into .git/config by default.
   • The git push fallback uses an explicit gitAuthEnv.

   The PR's own code comment in push_repo_memory.cjs documents this:

   pushSignedCommits authenticates via the git extraheader set by actions/checkout (and the gitAuthEnv fallback for the git-push path).

2. Add codemod to enforce persist-credentials: false on actions/checkout steps #31478 (2026-05-11) added a gh aw fix codemod that mechanically rewrites every actions/checkout step to persist-credentials: false — which removes the very extraheader that pushSignedCommits silently relied on. When users recompile after picking up the new codemod, the push_repo_memory job's checkout loses its credentials, the internal ls-remote origin fails with fatal: could not read Username for 'https://github.com', and the catch handler falls back to an unsigned git push that the ruleset rejects.

Why it wasn't caught

push_repo_memory.test.cjs from #29330 is a source-content test (expect(scriptContent).toContain(...)) rather than an integration test against a real persist-credentials: false checkout, so the implicit dependency on the extraheader was never exercised.

The one-line gitAuthEnv fix proposed above closes this gap explicitly, and an integration test that runs the action against a checkout configured with persist-credentials: false would prevent any future regression of the same shape.

[pelikhan]

Looking into this.