Skip to content

fix(hybrid-gate): stop failing the build when FLEET_REPO_TOKEN is absent - #34

Merged
forkwright merged 1 commit into
mainfrom
fix/fleet-token-optional
Aug 13, 2026
Merged

fix(hybrid-gate): stop failing the build when FLEET_REPO_TOKEN is absent#34
forkwright merged 1 commit into
mainfrom
fix/fleet-token-optional

Conversation

@forkwright

Copy link
Copy Markdown
Owner

Finding

full-gate-build's "Configure git credentials for fleet deps" step exits 1 whenever FLEET_REPO_TOKEN is empty — regardless of whether any fleet dependency actually needs it.

Dependabot-triggered runs read a separate secret store and receive no Actions secrets, so that token is always empty for them. Every dependabot PR in every adopting repo therefore fails the required gate by construction.

Evidence

From forkwright/aletheia:

  • dependabot PR #6679 (Aug 10) failed at this step with exit 1, skipping fmt / check / clippy / nextest entirely.
  • dependabot PR #6681, same repo, two hours earlier, had the identical step succeed.

That difference is not about what the PRs needed. It is about how each run happened to be triggered — which is why a caller-side needs_fleet_repo_token: false opt-out cannot express the condition either. A caller cannot know at declaration time whether this run will be handed the secret.

Correction

Warn and continue.

Every forkwright git dependency is public, so anonymous fetch succeeds. The token path stays for any future private dep — populate both the Actions and Dependabot secret stores at that point. A genuine missing-credential failure now surfaces at the fetch itself, with this warning immediately above it in the log, instead of pre-emptively failing runs that never needed the token.

This is not a new pattern

forkwright/aletheia already ships exactly this guard, with this reasoning, in its own .github/actions/fleet-git-credentials composite — used by its gate-coverage-scripts and gate-coverage-compile-checks jobs. The reusable's full-gate-build simply never adopted it.

A reusable workflow cannot reference a composite action from its own repo (./ resolves against the caller's checkout), so the duplication here is structural rather than an oversight. The step says so, and says to keep the two in sync by hand.

Blast radius

Confined to one conditional in one step, and it only ever converts a hard failure into a warning — it cannot cause a build to fail that previously passed. Adopting repos pin this workflow by SHA, so nothing moves until each bumps.

python3 -c "import yaml; yaml.safe_load(...)" parses clean.

Refs forkwright/aletheia#6684

The credential step exited 1 whenever the token was empty, regardless of
whether any fleet dep actually needed it. Dependabot-triggered runs read a
separate secret store and receive no Actions secrets, so the token is
always empty for them — which made every dependabot PR unmergeable by
construction.

Measured in aletheia: dependabot PR #6679 died at this step, while #6681
two hours earlier passed it. Whether a run sees the secret depends on how
it was triggered, not on what it needs, so a caller-side opt-out cannot
express the condition either.

Warn and continue instead. Every forkwright git dep is public, so
anonymous fetch succeeds; the token path stays for any future private dep.
A genuine missing-credential failure now surfaces at the fetch itself,
with this warning directly above it in the log.

This is the guard aletheia already ships in its own
.github/actions/fleet-git-credentials composite. A reusable workflow
cannot reference a composite from its own repo, so the duplication is
structural and noted as such in the step.

Refs forkwright/aletheia#6684
@forkwright
forkwright merged commit 54f1af7 into main Aug 13, 2026
1 of 2 checks passed
@forkwright
forkwright deleted the fix/fleet-token-optional branch August 13, 2026 14:13
forkwright added a commit to forkwright/aletheia that referenced this pull request Aug 13, 2026
## Why

The shared gate's "Configure git credentials for fleet deps" step exited
1 whenever `FLEET_REPO_TOKEN` was empty — regardless of whether any
fleet dependency needed it.

Dependabot-triggered runs read a **separate secret store** and receive
no Actions secrets, so that token is *always* empty for them. Every
dependabot PR therefore failed the required gate **by construction**,
before fmt / check / clippy / nextest ever ran.

## Evidence

- dependabot **#6679** (Aug 10) died at that step with `exit 1`.
- dependabot **#6681**, same repo, **two hours earlier**, passed the
identical step.

The difference is how each run was triggered, not what it needed — which
is also why a caller-side `needs_fleet_repo_token: false` cannot express
the condition. A caller cannot know at declaration time whether *this
run* will be handed the secret.

## What the bump brings

forkwright/.github#34 makes the step warn and continue. Every forkwright
git dependency is public, so anonymous fetch resolves; a genuine
credential failure now surfaces at the fetch itself with the warning
immediately above it in the log, rather than pre-emptively failing runs
that never needed a token.

`963532686` → `54f1af7c711546304409593695e1258a91004453`.

## This repo keeps `needs_fleet_repo_token: true`

Unchanged deliberately. It is standing insurance against anonymous-fetch
rate limiting on GitHub-hosted runners — the input's documented second
criterion — and `scripts/check-automation-pr-gates.py` enforces it
unconditionally whenever `Cargo.toml` resolves any forkwright git
dependency. The upstream change makes that input safe when the secret is
absent; it does not make the input unnecessary.

## Verification

This PR's own gate, plus the next dependabot PR reaching a real verdict
instead of dying at the credential step.

Refs #6684

Co-authored-by: Cody Kickertz <admin@forkwright>
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