`gh aw compile` produces different lockfiles for fork contributors vs the upstream CI checkout, with no in-repo way to make them match

[trask]

gh aw compile produces different lockfiles for fork contributors vs the upstream CI checkout, with no in-repo way to make them match

Summary

Contributors who run gh aw compile on a clone of their fork produce lockfile output that does not match the output produced by the same command run on the upstream repository in CI. The only difference is the scattered-cron minute, but it is enough that the repo's check-gh-aw-lockfiles job (git diff --exit-code after gh aw compile) always fails locally and the contributor has to hand-edit the cron value back before pushing.

The scattered-cron seed is derived from the local origin remote slug, so every fork produces a different value. CI uses the canonical open-telemetry/opentelemetry-java-instrumentation slug; my fork uses trask/opentelemetry-java-instrumentation, so I get a different minute than CI even on a clean checkout of main.

There is a CLI flag (--schedule-seed) that pins the seed and was fixed in #31098 to actually take effect, but there is no way to bake that value into the repository, so:

• Every contributor has to know about the flag.
• The repo's own CI command (gh aw compile --no-check-update) cannot be copied verbatim into contributor docs — it has to be rewritten with the upstream slug.
• Any contributor who runs the bare command, including agents/bots, produces a "stale lockfile" diff that looks like a real change.

Reproduction

# Clone a fork of a repo that uses gh-aw
git clone https://github.com/<your-fork>/<repo>.git
cd <repo>

# Identical to the CI command:
gh aw compile --no-check-update

git diff -- .github/workflows
# Lockfile diff shows only:
#   - cron: "<upstream-minute> */1 * * *"
#   + cron: "<fork-minute>     */1 * * *"

CI (which checks out under the canonical slug) produces no diff from the same command. So the repo's git diff --exit-code lockfile gate passes in CI and fails for every fork contributor.

Expected

Either:

• The bare gh aw compile command (no extra flags) produces the same output for any clone of the same commit of the same repository, regardless of what the local origin remote happens to point at, or
• The repository can declare a stable seed once (in a committed file the compiler reads), so contributors don't need to discover and pass --schedule-seed themselves.

Actual

The seed is taken from the local origin remote slug at compile time, with no way to override that from a committed file. --schedule-seed works (after #31098) but it's a per-invocation flag, so it doesn't help the common case of a contributor running gh aw compile the same way CI does.

Impact

For a repo with gh-aw workflows + a git diff --exit-code lockfile check (very normal pattern), every fork-based contributor has to:

1. Know that the cron drift is benign.
2. Either pass --schedule-seed <upstream-owner>/<repo> on every compile, or hand-revert the cron minute to match HEAD before committing.

Bots/automation that "just run gh aw compile" can't be expected to know either of those.

Related

• Bug: --schedule-seed is silently overridden by per-file git-remote detection during compile #31098 — --schedule-seed was previously silently ignored; now fixed, but it only helps if the contributor passes the flag.
• Fuzzy schedule scattering fails to parse GHE SSH remote URLs #31018, Fuzzy schedule requires an 'origin' remote #24384 — earlier discussion of scattered-cron seed behavior.

Environment

• gh aw v0.74.0
• Reproduced on Windows 11 (git-bash) and Linux. Not OS-specific.
• Repo: open-telemetry/opentelemetry-java-instrumentation, fork trask/opentelemetry-java-instrumentation.

[pelikhan]

@copilot the repo seed should be the upstream in a fork.