2 Commits
Author SHA1 Message Date
sneak 3a4a6bb21f Set a time limit on the canonical check job (closes #120)
check / check (push) Waiting to run
The canonical check workflow gave its job no time limit, so a hung
script/cibuild held the shared runner until the runner's own default.
The check job now sets timeout-minutes: 20. script/cibuild runs three
Docker builds (the test phase, the lint phase, then the image, which
runs both again), each held to the 5-minute build limit, plus the
bootstrap. REPO_POLICIES.md and both checklists name the limit among
what the workflow sets.

Model: opus-5-5
2026-10-07 09:04:00 +00:00
clawbot a04a76d59c Make the canonical package.json private instead of declaring MIT (closes #119)
check / check (push) Canceled after 0s
Repositories copy package.json to get prettier, and with "license": "MIT"
each of them declared MIT whatever its own licence is. "private": true
keeps yarn from printing "No license field" and makes no licence claim.
This repository's LICENSE and README License section are unchanged.

Model: opus-5-5
2026-10-07 11:02:12 +02:00
3 changed files with 19 additions and 16 deletions
+4
View File
@@ -29,6 +29,10 @@ fmt-check, and commit.
follows it. `REPO_POLICIES.md` and both checklists name the limit among what
the workflow sets. Not yet tried on the shared runner. Repositories pick this
up on their next re-vendor.
- 2026-10-07: The canonical `package.json` now has `"private": true` in place of
`"license": "MIT"` (issue 119), so a repository that copies it no longer
declares MIT whatever its own licence is. yarn does not print "No license
field" for a private package. This repository's own licence is unchanged.
- 2026-10-06: The canonical `.gitea/workflows/check.yml` now sets
`fetch-depth: 0` on its checkout step (issue 110), so CI fetches the history
and tags that `git describe --tags --always` needs, and a tagged repository
+1 -1
View File
@@ -1,5 +1,5 @@
{
"license": "MIT",
"private": true,
"devDependencies": {
"prettier": "3.8.1"
}
+14 -15
View File
@@ -298,21 +298,20 @@ style conventions are in separate documents:
workflow's `concurrency` block groups runs by workflow and branch
(`${{ github.workflow }}-${{ github.ref }}`) with `cancel-in-progress: true`,
so a new push cancels the older run on the same branch, queued or running, and
no other: runs for replaced commits do not hold up the shared runner. The
`check` job sets `timeout-minutes: 20`, so a hung build frees the shared
runner after 20 minutes. That allows for the three Docker builds
`script/cibuild` runs (the lint phase, the test phase, then the image, which
runs both again), each held to the 5-minute Docker build limit below, plus the
bootstrap. `script/cibuild` bootstraps, runs the gate phases, and then builds
the image, so a successful run means every check passed; a bare
`docker build .` does not carry the same guarantee, because its gate phases
may come from the cache. The image build is uncached and so runs the gate
phases a second time. That is the price of the rule above, and it is worth
paying: the image that ships is built from a run of its own gates rather than
from a cache entry. A separate workflow limited to `main` by a `branches` list
under `on: push` cannot be checked by review: to try a change to it, add the
feature branch to that list and push, then remove the branch from the list
again before merging. Keep any job in it that publishes behind
no other: runs for replaced commits do not hold up the shared runner.
`script/cibuild` bootstraps, runs the gate phases, and then builds the image,
so a successful run means every check passed; a bare `docker build .` does not
carry the same guarantee, because its gate phases may come from the cache. The
image build is uncached and so runs the gate phases a second time. That is the
price of the rule above, and it is worth paying: the image that ships is built
from a run of its own gates rather than from a cache entry. The `check` job
sets `timeout-minutes: 20`, so a hung build frees the shared runner after 20
minutes. That allows for the three Docker builds described above (the test
phase, the lint phase, then the image), each held to the 5-minute Docker build
limit below, plus the bootstrap. A separate workflow limited to `main` by a
`branches` list under `on: push` cannot be checked by review: to try a change
to it, add the feature branch to that list and push, then remove the branch
from the list again before merging. Keep any job in it that publishes behind
`if: github.ref_name == 'main'`, so the run from the feature branch publishes
nothing.