The canonical REPO_POLICIES.md, re-vendored under #196, says the Gitea workflow runs script/cibuild on push and checks out the repo as its only other step.
pixa's .gitea/workflows/check.yml also runs script/docker-smoke, added under #111 so that CI starts the image and waits for its healthcheck. Dropping the step loses that check from CI; keeping it needs the canonical policy changed. That choice is the owner's.
Model: opus-5-5
The canonical `REPO_POLICIES.md`, re-vendored under https://git.eeqj.de/sneak/pixa/issues/196, says the Gitea workflow runs `script/cibuild` on push and checks out the repo as its only other step.
pixa's `.gitea/workflows/check.yml` also runs `script/docker-smoke`, added under https://git.eeqj.de/sneak/pixa/issues/111 so that CI starts the image and waits for its healthcheck. Dropping the step loses that check from CI; keeping it needs the canonical policy changed. That choice is the owner's.
Model: opus-5-5
clawbot
self-assigned this 2026-10-04 22:29:51 +02:00
Question for @sneak: should pixa's CI keep its script/docker-smoke step?
The canonical REPO_POLICIES.md says the Gitea workflow checks out the repo and runs script/cibuild, nothing else. pixa's workflow also runs script/docker-smoke, which starts the built image and waits for its health check to report healthy (added under #111). That catches an image that builds but does not start, which script/cibuild alone does not.
Keep the step, and let the canonical policy allow a repo to add a step after script/cibuild that starts the image (recommended: it is the only CI check that the container actually runs, and the policy change lives in sneak/prompts).
Drop the step to match the policy as it stands; pixa then has no CI check that the image starts.
Nothing else waits on this.
Model: opus-5-5
Question for @sneak: should pixa's CI keep its `script/docker-smoke` step?
The canonical `REPO_POLICIES.md` says the Gitea workflow checks out the repo and runs `script/cibuild`, nothing else. pixa's workflow also runs `script/docker-smoke`, which starts the built image and waits for its health check to report healthy (added under https://git.eeqj.de/sneak/pixa/issues/111). That catches an image that builds but does not start, which `script/cibuild` alone does not.
- Keep the step, and let the canonical policy allow a repo to add a step after `script/cibuild` that starts the image (recommended: it is the only CI check that the container actually runs, and the policy change lives in `sneak/prompts`).
- Drop the step to match the policy as it stands; pixa then has no CI check that the image starts.
Nothing else waits on this.
Model: opus-5-5
clawbot
removed their assignment 2026-10-04 22:42:56 +02:00
sneak
was assigned by clawbot2026-10-04 22:42:56 +02:00
Short answer: it is not needed for anything make check misses in the code; it was added (#111) to catch an image that builds but will not start, such as a broken entrypoint or a data directory it cannot write, which make check never runs. By your rule that make check covers what needs covering, the step goes and the Gitea workflow runs script/cibuild only, as the canonical policy says. One small reviewed PR on next, when pixa next has a manager. If you would rather keep the start check, it would move into make check instead; say so here.
Model: opus-5-5
Short answer: it is not needed for anything `make check` misses in the code; it was added (https://git.eeqj.de/sneak/pixa/issues/111) to catch an image that builds but will not start, such as a broken entrypoint or a data directory it cannot write, which `make check` never runs. By your rule that `make check` covers what needs covering, the step goes and the Gitea workflow runs `script/cibuild` only, as the canonical policy says. One small reviewed PR on `next`, when pixa next has a manager. If you would rather keep the start check, it would move into `make check` instead; say so here.
Model: opus-5-5
sneak
was unassigned by clawbot2026-10-21 12:08:39 +02:00
clawbot
self-assigned this 2026-10-21 12:08:39 +02:00
clawbot
added this to the 1.0.0 milestone 2026-10-21 12:51:43 +02:00
Plan, as an implementer's brief: one PR to next that removes the script/docker-smoke step from .gitea/workflows/check.yml, so the workflow checks out the repo and runs script/cibuild only. script/docker-smoke and make docker-smoke stay as local tools. Any present-tense sentence in the repo saying CI runs script/docker-smoke is corrected; dated TODO.md history stays as written. No Go code or test changes. Then an independent review and a squash-merge to next, ahead of #307.
Model: opus-5-5
Plan, as an implementer's brief: one PR to `next` that removes the `script/docker-smoke` step from `.gitea/workflows/check.yml`, so the workflow checks out the repo and runs `script/cibuild` only. `script/docker-smoke` and `make docker-smoke` stay as local tools. Any present-tense sentence in the repo saying CI runs `script/docker-smoke` is corrected; dated `TODO.md` history stays as written. No Go code or test changes. Then an independent review and a squash-merge to `next`, ahead of https://git.eeqj.de/sneak/pixa/issues/307.
Model: opus-5-5
Built in #322: the workflow checks out the repo and runs script/cibuild only; script/docker-smoke and make docker-smoke stay for running by hand, and the script's header comment no longer says the workflow runs it.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/pixa/pulls/322: the workflow checks out the repo and runs `script/cibuild` only; `script/docker-smoke` and `make docker-smoke` stay for running by hand, and the script's header comment no longer says the workflow runs it.
Model: opus-5-5
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.
The canonical
REPO_POLICIES.md, re-vendored under #196, says the Gitea workflow runsscript/cibuildon push and checks out the repo as its only other step.pixa's
.gitea/workflows/check.ymlalso runsscript/docker-smoke, added under #111 so that CI starts the image and waits for its healthcheck. Dropping the step loses that check from CI; keeping it needs the canonical policy changed. That choice is the owner's.Model: opus-5-5
Question for @sneak: should pixa's CI keep its
script/docker-smokestep?The canonical
REPO_POLICIES.mdsays the Gitea workflow checks out the repo and runsscript/cibuild, nothing else. pixa's workflow also runsscript/docker-smoke, which starts the built image and waits for its health check to report healthy (added under #111). That catches an image that builds but does not start, whichscript/cibuildalone does not.script/cibuildthat starts the image (recommended: it is the only CI check that the container actually runs, and the policy change lives insneak/prompts).Nothing else waits on this.
Model: opus-5-5
why does it need a check the image starts? make check should cover everything that it needs to cover.
Short answer: it is not needed for anything
make checkmisses in the code; it was added (#111) to catch an image that builds but will not start, such as a broken entrypoint or a data directory it cannot write, whichmake checknever runs. By your rule thatmake checkcovers what needs covering, the step goes and the Gitea workflow runsscript/cibuildonly, as the canonical policy says. One small reviewed PR onnext, when pixa next has a manager. If you would rather keep the start check, it would move intomake checkinstead; say so here.Model: opus-5-5
Plan, as an implementer's brief: one PR to
nextthat removes thescript/docker-smokestep from.gitea/workflows/check.yml, so the workflow checks out the repo and runsscript/cibuildonly.script/docker-smokeandmake docker-smokestay as local tools. Any present-tense sentence in the repo saying CI runsscript/docker-smokeis corrected; datedTODO.mdhistory stays as written. No Go code or test changes. Then an independent review and a squash-merge tonext, ahead of #307.Model: opus-5-5
Built in #322: the workflow checks out the repo and runs
script/cibuildonly;script/docker-smokeandmake docker-smokestay for running by hand, and the script's header comment no longer says the workflow runs it.Model: opus-5-5