mr.zeroandClaude Opus 5
4192fc366e
The marketplace held only MCP servers so far. These are skills for the work that keeps costing manual effort and quietly breaking: - ttg-publish-module — releasing a library, and verifying from a clean external project that the release is actually fetchable. Encodes the trap that cost the most: Gitea redirects old repo paths, but not Go module paths, so a repo can be reachable while `go get` fails. - ttg-move-repo — moving a repo and following it through every place that names it, including the ones redirects do not cover. - ttg-new-repo — creating one in the right org and registering it, so it cannot end up absent from the clone list the way batocera-store did. - ttg-ci-enroll — wiring a repo into the build, and the usual failure where the config exists but the repo was never registered. - ttg-audit-forge — the drift check between forge, clone list, wiki, catalog and CI. - ttg-update-docs — README, wiki page and the public site (Vue page plus both locale files) after a change. The rules stay in REPO_REFACT.md, WIKI_CONNECTION.md and ECOSYSTEM_PLAN.md; the skills read them instead of carrying a second copy that drifts. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
53 lines
3.6 KiB
Markdown
53 lines
3.6 KiB
Markdown
---
|
||
name: ttg-ci-enroll
|
||
description: Wire a TTG repo into the Woodpecker build and prove the pipeline actually runs — the one-line platform config, the builder image, registration, and the catalog entry it publishes to. Use when a repo should start building, or when a build is not running even though the config is in place ("kösd be a CI-be", "nem fut a build", "enroll CI").
|
||
allowed-tools: Bash, Read, Edit, Write, Grep, Glob
|
||
---
|
||
|
||
# ttg-ci-enroll
|
||
|
||
Egy repo bekötése a buildbe. A leggyakoribb hiba nem a konfig hiánya, hanem hogy **a konfig megvan, de a repo nincs regisztrálva** — ilyenkor semmi nem történik, és nincs hibaüzenet sem.
|
||
|
||
## Hogyan épül fel a build
|
||
|
||
A repo `.woodpecker.yaml`-ja egyetlen sor:
|
||
|
||
```yaml
|
||
# The CI pipeline is served by the update server: GET /build/config?platform=ebitengine
|
||
platform: ebitengine
|
||
```
|
||
|
||
A tényleges pipeline-t a WarpEngine **config-extension** szolgáltatása állítja elő (`/build/config`), a builder image-eket pedig a `services/teletypegames` `apps/api/config/initializers/warp_engine.rb`-je sorolja fel (`c.ci_platforms`). Ezért egy image-bump egyetlen sor ott, nem hét repóban.
|
||
|
||
Támogatott platformok: `c64`, `tic80`, `ebitengine`, `love`, `godot`, `bevy`, `phaser`.
|
||
|
||
## Lépések
|
||
|
||
1. **Platform-konfig.** Ha nincs, hozd létre a `.woodpecker.yaml`-t a fenti egy sorral. **Figyelj a kiterjesztésre:** mindkettő él a vadonban (`.woodpecker.yaml` és `.woodpecker.yml`), keresd mindkettőt, mielőtt hiányzónak nyilvánítod. Új repóhoz a `.yaml` a preferált.
|
||
|
||
2. **Toolchain.** A platform `build/<platform>-tools` repója adja a Makefile-mintát (`example-makefile.make`) és a builder image Dockerfile-ját. Új projekt Makefile-ja innen induljon, ne másolásból.
|
||
|
||
3. **Go projekt esetén `GOPRIVATE`.** Ha a repo saját modulra (`engines/…`) támaszkodik, a Makefile-ban legyen `export GOPRIVATE = git.teletypegames.org` — a saját modulјaink nincsenek a proxy.golang.org-on. Ha `replace ... => ../<repo>` direktíva van a `go.mod`-ban, **az CI-ben biztosan bukik** (testvérkönyvtárat vár): adasd ki a függőséget rendes verzióval a `ttg-publish-module` skillel, és dobd el a replace-t.
|
||
|
||
4. **Regisztráció a Woodpeckerben.** A repo aktiválása a Woodpecker felületén történik; a WarpEngine oldali nyilvántartás ebből szinkronizálódik.
|
||
|
||
5. **Ellenőrzés.** Mit tud a rendszer:
|
||
```sh
|
||
curl -s https://teletypegames.org/api/ci/pipelines
|
||
```
|
||
A sorokban `repo_owner`, `repo_name`, `platform`, `active`, `last_pipeline_status`. Amíg a repo nincs a listában, nem fut rá build.
|
||
|
||
## Ha „be van kötve", mégsem fut
|
||
|
||
Ellenőrizendő sorrendben:
|
||
|
||
- **Tényleg a listában van?** A `/api/ci/pipelines` a mérce, nem a repóban lévő fájl.
|
||
- **Elavult tulajdonos.** A tábla `repo_owner`-je org-váltás után a régi orgot mutathatja, amíg a szinkron nem futott. A szinkron `woodpecker_repo_id`-ra kulcsol és a távoli adatból frissíti a tulajdonost, tehát magától rendbe jön — de addig félrevezet.
|
||
- **Tag-esemény.** Ha a pipeline `when: event: tag`-re van kötve (publikáló lépések), a sima push nem indítja. Nézd meg, hogy a repón engedélyezett-e a tag-build.
|
||
- **Secret jogok.** A publikáló lépések tokenjének `package:write` kell, és org-váltás után a leírásában szereplő cél is elavulhat.
|
||
- **`last_pipeline_status`.** A `failure`/`error` érték már önmagában irány — ne a konfigot kezdd el javítgatni, előbb nézd meg, mi bukott.
|
||
|
||
## A végén
|
||
|
||
Ha a bekötés új platformot tesz élővé, az `ECOSYSTEM_PLAN.md` platform-lefedettségi táblázatában javítsd az „Aktív CI" oszlopot.
|