fix(ci): derive IMAGE from github.repository, not the schedule-empty event payload

`${{ github.event.repository.name }}` resolves to EMPTY on `schedule`
events since the Gitea upgrade (now 1.27.0), so IMAGE would resolve to
"justin/" and the image build would fail with

  ERROR: failed to build: invalid tag
  "192.168.0.2:1234/justin/:latest": invalid reference format

This is confirmed in seed-mcp and opsramp-docs, which share this
workflow's lineage. Here the bug is still latent: the monthly refresh
has been failing earlier, during the epa_ppls scrape, when the job
container disappears (`docker daemon ping ... context deadline
exceeded`) roughly 3 h in — a separate runner-side problem that this
commit does NOT address.

- IMAGE now comes from `${{ github.repository }}` (run context, not the
  event payload — `github.repository_owner` from the same source was
  resolving fine all along).
- The package-link and registry-GC steps take the bare repo name from
  `${GITHUB_REPOSITORY##*/}` (POSIX, safe under dash).
- New `Verify image name resolves` step fails in seconds instead of
  after a full scrape if this ever regresses.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01FnVuG79cYPcRLTp4pC8ujR
This commit is contained in:
2026-09-01 11:11:50 -04:00
co-authored by Claude Opus 5
parent 23c7a3d524
commit 8e12f6af8e
3 changed files with 38 additions and 8 deletions
+6 -2
View File
@@ -146,8 +146,12 @@ identifiers that the LLM reads.
You do NOT need to edit the IMAGE env or the `--package` arg in the
workflows. Both derive from the repo at runtime via
`${{ github.repository_owner }}` and
`${{ github.event.repository.name }}`. So a clone into a repo named
`${{ github.repository }}` and `${GITHUB_REPOSITORY##*/}`. Do **not**
use `${{ github.event.repository.name }}` — it resolves to EMPTY on
`schedule` events (Gitea >= 1.27), which silently builds the tag
`<registry>/<owner>/:latest` and fails the build *after* the full
scrape; the `Verify image name resolves` step guards it. So a clone
into a repo named
`my-product-docs` automatically pushes the container as
`<owner>/my-product-docs:latest` and links the package to its own
repo. (`github.*` is Gitea Actions' inherited GitHub-Actions