${{ github.event.repository.name }} resolves to empty on schedule events since the Gitea upgrade (now 1.27.0), so IMAGE became justin/ and the image build failed with invalid tag "192.168.0.2:1234/justin/:latest": invalid reference format — after the whole scrape + reindex had already succeeded.
IMAGE (and, where present, the metadata-action images: + OCI labels) now use ${{ github.repository }} — the run context, not the event payload. github.repository_owner from that same source was resolving fine all along.
Package-link / registry-GC steps take the bare repo name from ${GITHUB_REPOSITORY##*/} (POSIX, dash-safe).
New Verify image name resolves step fails in seconds rather than after a multi-hour scrape if this regresses.
`${{ github.event.repository.name }}` resolves to **empty** on `schedule` events since the Gitea upgrade (now 1.27.0), so `IMAGE` became `justin/` and the image build failed with `invalid tag "192.168.0.2:1234/justin/:latest": invalid reference format` — after the whole scrape + reindex had already succeeded.
- `IMAGE` (and, where present, the metadata-action `images:` + OCI labels) now use `${{ github.repository }}` — the run context, not the event payload. `github.repository_owner` from that same source was resolving fine all along.
- Package-link / registry-GC steps take the bare repo name from `${GITHUB_REPOSITORY##*/}` (POSIX, dash-safe).
- New `Verify image name resolves` step fails in seconds rather than after a multi-hour scrape if this regresses.
`${{ github.event.repository.name }}` resolves to EMPTY on `schedule`
events since the Gitea upgrade between 2026-07-01 and 2026-08-01, so
IMAGE became "justin/" and the monthly refresh died at the last step:
ERROR: failed to build: invalid tag
"192.168.0.2:1234/justin/:latest": invalid reference format
Both the 2026-08-01 and 2026-09-01 refreshes scraped, committed, pushed
and reindexed successfully, then failed to build the image — so the
corpus on main is current but the published container has been stale
since the 2026-07-01 run.
- 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 ~30 min scrape if this ever regresses.
Same fix applies to image-only.yml, which only escaped the bug because
push/workflow_dispatch events still carry the repository payload.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01FnVuG79cYPcRLTp4pC8ujR
claude
merged commit 953e0f10f9 into main2026-09-01 11:19:09 -04:00
claude
deleted branch fix/image-name-on-schedule2026-09-01 11:19:09 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
${{ github.event.repository.name }}resolves to empty onscheduleevents since the Gitea upgrade (now 1.27.0), soIMAGEbecamejustin/and the image build failed withinvalid tag "192.168.0.2:1234/justin/:latest": invalid reference format— after the whole scrape + reindex had already succeeded.IMAGE(and, where present, the metadata-actionimages:+ OCI labels) now use${{ github.repository }}— the run context, not the event payload.github.repository_ownerfrom that same source was resolving fine all along.${GITHUB_REPOSITORY##*/}(POSIX, dash-safe).Verify image name resolvesstep fails in seconds rather than after a multi-hour scrape if this regresses.`${{ github.event.repository.name }}` resolves to EMPTY on `schedule` events since the Gitea upgrade between 2026-07-01 and 2026-08-01, so IMAGE became "justin/" and the monthly refresh died at the last step: ERROR: failed to build: invalid tag "192.168.0.2:1234/justin/:latest": invalid reference format Both the 2026-08-01 and 2026-09-01 refreshes scraped, committed, pushed and reindexed successfully, then failed to build the image — so the corpus on main is current but the published container has been stale since the 2026-07-01 run. - 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 ~30 min scrape if this ever regresses. Same fix applies to image-only.yml, which only escaped the bug because push/workflow_dispatch events still carry the repository payload. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01FnVuG79cYPcRLTp4pC8ujR