R1 plan and ADR 0008: CI signs releases; README section on CI
CI / build (push) Successful in 8m0s

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT
This commit is contained in:
2026-10-06 12:19:00 +02:00
co-authored by Claude Opus 5.5
parent 1fade6287b
commit 6b6bb975f5
3 changed files with 62 additions and 0 deletions
+13
View File
@@ -20,6 +20,19 @@ This runs the host-side unit tests (`test/`, `native` environment), then builds
The framework is rebuilt with the TLS settings in `platformio.ini` (`custom_sdkconfig`, ADR 0006), so the first build after a fresh checkout takes about 4 minutes; later builds take under a minute.
## CI and releases
Gitea Actions runs the same thing on every push (`.gitea/workflows/ci.yml`, docs/milestones/R1.md). Pushing a tag `v*` also publishes a release on Gitea with:
- `roro9stack-<version>.ota`, the signed Update File;
- `roro9stack-<version>-factory.bin`, the whole flash image for a first install over USB;
- `roro9stack-<version>.elf.gz`, to decode crash reports from that build;
- `SHA256SUMS`.
CI signs with the project's key, held as a repository secret (ADR 0008). Debug Builds are built but never published: each carries its builder's Debug Console token.
`scripts/ota_verify.py <file.ota>` checks an Update File on a PC the way a device does. `scripts/release_build.sh` and `scripts/release_publish.py` are what the workflow runs; they work the same by hand.
## Flash
1. Connect the Cardputer by USB-C.
+17
View File
@@ -0,0 +1,17 @@
# CI signs releases with the project's key
A tag `v*` is built, signed and published by Gitea Actions with nobody at a keyboard. The signing key of ADR 0003 is therefore held twice: in `~/.config/roro9stack/ota-key.pem` on the development machine, as before, and as the repository secret `OTA_SIGNING_KEY`, which the release step writes to a file for as long as it runs.
We chose this over signing by hand after CI has built (a command per release, the key in one place), and over a second key for CI that the firmware would also trust. A release that needs a manual step isn't made on the day it's ready, and issue #6, the device installing releases by itself, needs releases that are always there and always signed.
## What it costs
- **Whoever can run a workflow in this repository can sign firmware every device accepts.** That means: anyone who can push to it, the runner's host and whoever administers it, and the Gitea instance with its database, where the secret is stored. Before, it took the development machine.
- The runner executes jobs **on its own host**, not in a container, as a user who can use Docker. A workflow is not confined.
- Pull requests from forks must never run with this secret. Gitea doesn't pass secrets to them; the workflow also only runs on pushes and by hand.
## What limits it
- The release step checks the signed file against the public key in the sources it built (`scripts/ota_verify.py`): a wrong or replaced secret stops the release instead of publishing a file no device takes.
- ADR 0003's way out stays: a firmware release can carry a new public key. If the secret is ever in doubt, make a new pair, ship it in a release signed with the old key, and replace the secret.
- A device still only installs what it's told to (until #6), keeps a new image on Probation, and rolls back one that doesn't hold.
+32
View File
@@ -0,0 +1,32 @@
# R1 — Releases
**Status:** in progress (branch `ci`): CI and signed releases on Gitea (issue #5). The Issues App (#4) and updates from Gitea (#6) come after; #6 waits for this.
**Goal:** a tag is a release, built the same way every time and published where a device can find it.
## CI and releases (issue #5)
Until now the tests, the builds, the signing and the flashing all happened on one machine, through `scripts/ci.sh` and `scripts/flash.sh`. Nothing was published.
### Decisions (design round 2026-10-06)
| # | Decision |
|---|---|
| Q151 | Every push, to any branch: the host tests and both builds. A tag `v*`: the same, then a release. |
| Q152 | **CI signs.** The signing key is the repository secret `OTA_SIGNING_KEY`; a tag push makes a complete, signed release with no manual step (ADR 0008). |
| Q153 | The Debug Build is built in CI with a token of the runner's own, to prove it compiles, and **isn't published**: it would hand everyone its Debug Console token. |
| Q154 | Pull requests from forks don't start a run. |
| Q155 | A release carries `roro9stack-<version>.ota` (signed), `-factory.bin` for USB, `.elf.gz` to decode crashes, and `SHA256SUMS`. |
| Q156 | Its text is the tag's message, what the files are, and the commits since the tag before. |
| Q157 | No cache service to begin with: measure first. |
| Q158 | Reproducible builds aren't needed for signing any more (Q152); not pursued here. |
| Q159 | **The tags from before CI get their releases too**, v0.1.0 to v0.10.0, built from each tag's own sources by running the workflow by hand. |
| Q160 | Actions is switched on for the repository. |
### 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 <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/ota_verify.py`** checks an Update File as a device does, on a PC.