twisla/roro9stack
Public Access
1
0
Fork 0
Code Issues 52 Pull Requests 1 Actions 2 Packages Releases 15 Activity

R1 plan: CI as built on the container runner
CI / build (push) Successful in 8m5s
Details

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT
This commit is contained in:
twisla
2026-10-06 12:52:43 +02:00
co-authored by Claude Opus 5.5
parent db7e6ccc18
commit a94c14f000
1 changed files with 13 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/milestones/R1.md
+13 -4
View File
@@ -25,8 +25,17 @@ Until now the tests, the builds, the signing and the flashing all happened on on
### As built ### As built
- **One workflow, `.gitea/workflows/ci.yml`, one job.** The runner (`runner0`) executes jobs on its own host, where Docker is, so the steps are plain shell and the build runs in the project's image through `scripts/ci.sh`, exactly as on a developer's machine. The toolchains live in the same `roro9stack-pio` Docker volume, on the runner: that is the cache. - **One workflow, `.gitea/workflows/ci.yml`, one job**, on the runner `runner0` (label `ubuntu`). The job asks for a `python:3.12-slim` container, installs git, a compiler, openssl and PlatformIO, and runs the same scripts as a developer's machine. No Docker inside the job.
- **No JavaScript actions:** the host has no Node. The checkout is four git commands. - **The cache is a Docker volume**, `roro9stack-pio`, mounted at `/pio`; the runner's `config.yaml` allows it under `container.valid_volumes`. A first run downloads about 1 GB and rebuilds the framework (17 minutes); with the volume filled, tests and both builds take about 6.
- **The runner's label** is registered as `ubuntu://docker:ubuntu:resolute`, the whole string, and that is what `runs-on` has to say. It looks like `ubuntu:docker://ubuntu:resolute` was meant, which would run jobs in a container; the workflow would then need Docker inside that container, or a rewrite. As it is, it works. - **No JavaScript actions**, so the image needs no Node and nothing is fetched from GitHub: the checkout is four git commands.
- **`scripts/release_build.sh <checkout> <out>`** builds a tag's own sources with today's build image and signing tools, signs, verifies, and writes the files and the release's text. **`scripts/release_publish.py`** creates the Gitea release or completes it; run twice, it replaces what's there. Both run the same on a developer's machine. - **`scripts/_docker.sh`** runs the command in place when `RORO_NO_DOCKER` is set (a CI job is already in a build container), and in the project's image otherwise. The Debug Build's token is made on the spot in CI and goes with the container.
- **`scripts/release_build.sh <checkout> <out>`** builds a tag's own sources with today's tools, signs, verifies against the public key in those sources, and writes the files and the release's text. **`scripts/release_publish.py`** creates the Gitea release or completes it; run twice, it replaces what's there. Both run the same on a developer's machine.
- **`scripts/ota_verify.py`** checks an Update File as a device does, on a PC. - **`scripts/ota_verify.py`** checks an Update File as a device does, on a PC.
- **The job's own token** (`secrets.GITEA_TOKEN`) is enough to create a release and upload its files.
- **Old tags.** v0.1.0 to v0.3.0 are from before the framework was rebuilt with our settings (ADR 0006) and can't link against a rebuilt one left in the cache: the release build puts the stock framework libraries back for them. v0.1.0 to v0.2.1 have no public key in their sources (Firmware Updates came with v0.3.0); their files are checked against today's.
### How it went
- **The runner's label took three tries.** Registered as `ubuntu://docker:ubuntu:resolute` and then as `ubuntu::docker://...`, Gitea took the whole string for the label's name; with the first, jobs ran on the runner's host itself. The first version of the workflow was written for that (plain shell, `docker run` for the build) and published v0.10.0 that way. `ubuntu:docker://docker.gitea.com/runner-images:ubuntu-latest` is the form that works.
- **Gitea 1.27's API can't cancel a run that isn't finished**, only delete a finished one; switching Actions off and on for the repository doesn't either. Runs queued for a label that no longer exists stay queued until cancelled in the web UI.
- **CI's image isn't byte-identical to a local build of the same tag** (same size, different bytes). Not pursued (Q158).