diff --git a/docs/milestones/R1.md b/docs/milestones/R1.md index 1a82e6c..1410850 100644 --- a/docs/milestones/R1.md +++ b/docs/milestones/R1.md @@ -25,8 +25,17 @@ Until now the tests, the builds, the signing and the flashing all happened on on ### 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. -- **No JavaScript actions:** the host has no Node. The checkout is four git commands. -- **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. -- **`scripts/release_build.sh `** 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. +- **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. +- **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. +- **No JavaScript actions**, so the image needs no Node and nothing is fetched from GitHub: the checkout is four git commands. +- **`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 `** 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. +- **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).