Expand RENOVATE_REPOSITORIES from the 7 game/plaza repos to the full set,
adding the shared libraries (achievements, api-core, app-ui, auth, cms,
config, create-game, discord-bot, games-registry, gen, media, omiru,
platform, ui), infra (compose image tags), and this workflows repo itself
(its github.com actions). Onboarding is enabled, so each newly-listed repo
gets a "Configure Renovate" PR adding the shared preset.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Wire an optional read-only GITHUB_COM_TOKEN so Renovate can reach
api.github.com (changelogs + actions/checkout-style updates) without
rate limiting, and disable management of the internal Gitea reusable
workflow `played/workflows` (it's a @main ref, not a github.com action).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Scheduled Renovate bot (renovate.yml) + shared preset (renovate-config.json)
that every game/plaza repo extends, so dependency bumps land the same way
across repos. @played/* grouped together, third-party non-major batched.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two failing runs across refaire (run 1709) and rememed (run 1624)
both crash at the same step (`Set up Docker Buildx`) with a node error
on dist/index.js line 1, AND both reference the same act cache dir:
/root/.cache/act/6a647958c11e138a6cfcaf32d2b372bc8e0c97871d617bfb441d003d505b77cf
act keys remote-action cache entries by repo URL alone — pinning to
`@v3.10.0` doesn't help, every game that uses `docker/setup-buildx-
action` lands in the same dir. When you push N games at once on
home-runner-1, the act-runner does parallel `git clone` ops into that
shared dir; the loser's pull aborts ("worktree contains unstaged
changes") and leaves dist/ half-written, so the next job's `node
dist/index.js` throws on line 1 → step fails. That's the entire flake.
Fix: drop the two remote actions that were racing — setup-buildx-action
and build-push-action — and replace them with inline `docker buildx
create` + `docker buildx build --push` shell. Nothing is fetched from
GitHub at runtime, no cache dir is shared, the failure mode disappears.
Same image, same tags, same registry mirror, same cache-from/cache-to
shape, same secret-files mount (`--secret id=...,src=...`). Each job
gets a uniquely-named builder (`builder-<game>-<api-core|web>`) and a
teardown step so the runner host's docker state doesn't accumulate
abandoned builders.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mode=max was re-uploading the bun install cache mount (~40–60s per
build, ~90s combined for api-core + web) to the Gitea OCI registry
on every push, even when source hadn't changed. That single export
accounts for most of the delta between 1-minute and 3-minute deploys.
mode=min only exports the final stage's layers. The trade-off is a
few-second tax on cold buildkitd starts (the installer stage no
longer warms from registry cache), but the per-push savings dwarf it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three reliability+speed changes to the reusable build-deploy-game workflow:
- Pin actions/checkout, docker/setup-buildx-action, docker/build-push-action
to immutable patch tags (v4.2.2, v3.10.0, v6.16.0). Moving major-version
tags (`@v3`/`@v6`) gave the act-runner non-deterministic cache hashes; the
remplir 1541 failure was act re-using a partial cache dir for `@v3` of
docker/login-action with only `.gitignore` present and no `dist/index.js`.
- Replace docker/login-action with an inline `docker login --password-stdin`
shell step in both build jobs. One less remote-action download per job =
one less surface for the act partial-cache failure mode that broke 1541.
- Decouple build-web from deploy-api-core. Web build only needs the git
checkout, not a running api-core (vite build is offline). deploy-web now
gates on [build-web, deploy-api-core] so the runtime ordering is still
api-core-before-web while the two image builds can run in parallel if the
runner has any concurrency.
Also: drop the shared played/bun-cache references (was causing thrashing
between games writing to the same `:latest` tag) and flip per-game cache
to mode=max so the expensive bun-install + turbo-build layers are
actually reused on subsequent runs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drives the standard four-stage build-api-core → deploy-api-core → build-web
→ deploy-web pipeline for a played game. Game repos invoke via:
jobs:
deploy:
uses: played/workflows/.gitea/workflows/build-deploy-game.yml@main
with:
game-id: <slug>
secrets: inherit
The caller's BUILD_ENV / NPMRC / REGISTRY_* / PLAYED_* /
STEP_CA_PROVISIONER_PASSWORD are inherited; `game-id` parameterizes the
VM paths (~/<id>, ~/<id>-secrets) and the docker tag context.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
enricobuehler