mroberts/claude-sbx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Record the verified CI path and its token requirement
build / Build and push image (push) Successful in 30s
Details

Browse Source 
The registry rejects the automatic token, so the workflow needs a personal access
token scoped to package read and write, and the runner label must match one the
forge actually has. Both cost a failed run to discover.
This commit is contained in:
mroberts
2026-07-31 09:06:05 -05:00
parent 2b61c3a639
commit 9be4122580
1 changed files with 18 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+18 -1
View File
@@ -29,6 +29,12 @@ Until it is fixed, this image builds and pushes correctly but produces a sandbox
none of its contents. **Use `mise run ai:sbx -- setup` instead** — it installs the same none of its contents. **Use `mise run ai:sbx -- setup` instead** — it installs the same
configuration and plugins into a stock sandbox at runtime, and works on 0.37.x today. configuration and plugins into a stock sandbox at runtime, and works on 0.37.x today.
The pipeline itself is verified. CI builds and publishes on every push to `main` and
every tag, and the published image pulls and contains what it should: 17 enabled
plugins, mise, the hooks and skills, and no credentials or transcripts in any layer.
What is unverified is the only thing that matters at runtime — whether a sandbox
created from it sees any of that — and it will not until #366 is fixed.
## What the image contains ## What the image contains
| Path | Source | | Path | Source |
@@ -70,10 +76,21 @@ regctl image import git.mroberts.dev/mroberts/claude-sbx:v1 image.tar
Plain `ubi:regclient/regclient` installs `regbot` rather than `regctl`; the `matching` Plain `ubi:regclient/regclient` installs `regbot` rather than `regctl`; the `matching`
filter above picks the right asset. `.gitea/workflows/build.yml` does the same on tag filter above picks the right asset. `.gitea/workflows/build.yml` does the same on tag
pushes and on `main`, authenticating with the automatic `GITEA_TOKEN`. pushes and on `main`.
Pulls are unaffected by the Cloudflare limit, which caps uploads only. Pulls are unaffected by the Cloudflare limit, which caps uploads only.
### CI authentication
The workflow authenticates with a `REGISTRY_TOKEN` secret holding a personal access
token scoped to **package: Read and Write**, and nothing else. The automatic
`GITEA_TOKEN` does not work: the package registry rejects it as `unauthorized`, and
adding `permissions: packages: write` to the job changes nothing.
The job runs on `runs-on: linux`, matching the self-hosted runner's label. There is no
`ubuntu-latest` runner on this forge, and a workflow naming one is discarded silently —
no queued run, no error, nothing in the Actions tab.
## Consuming ## Consuming
```toml ```toml