irisandClaude Opus 5
17d873ab7c
A component now declares its ways of being built in one list -- `modes: ["release", "debug"]`, the first the default -- and every command it runs is handed the mode as its last argument, so a project whose script takes `release` or `debug` names that script once. A field may instead be written per mode, which is the escape hatch for the commands that cannot take the word: cargo takes `--release` or nothing, and its profile for the unoptimised build is called `dev` while the directory it writes is called `debug`, so no single word serves as both the flag and the path. A command written per mode is not handed the word as well; it already is the answer, and a stray argument to a service binary is a process that will not start. One list rather than gathering names from whichever fields happened to mention them is what makes a mode missing from one part unsayable: every per-mode map is checked against it, so a gap is named rather than resolved to some other mode's command. Which mode to build in and whether to strip are the build machine's -- there is one checkout and one set of outputs, so a per-device mode would have two phones rebuilding over each other silently. Which of the finished builds a phone installs stays that phone's. Neither choice is part of the acceptance gate, so both have to be carried across the components list being rewritten, by acceptance and by the self entry's startup reconciliation alike; without the second a mode chosen for this server's own component would not survive the restart that applies it. A mode switch moves no commit, so `builtMode` is recorded beside `builtFrom`. Without it a component built in debug and switched to release reads as current and serves the debug build for ever -- and for an APK nothing else notices, because the "never built at all" check finds any variant under the component's directory. Each component card gains a settings sheet behind a gear at the row's right-hand end, holding the mode, which build to install, strip, and an Enrol button. The variant picker moved into it: on the card the two read as one choice, both saying debug and release, and they are not. The row's text is now bounded and truncates, so a long status can no longer push the log and settings buttons off the edge. `enroll:` is a declared command whose one line of stdout is a URL for the phone to open after installing -- generic on purpose, run per press since such a link is one-shot and carries a credential, and in the acceptance gate because it runs on the build machine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
37 lines
1.2 KiB
Bash
Executable File
37 lines
1.2 KiB
Bash
Executable File
#!/bin/sh
|
|
# "Builds" this project's daemon, which is a shell script and so needs no
|
|
# building at all. What it actually does is take a few seconds and report
|
|
# progress, because that is the thing worth having: a component slow enough
|
|
# to watch a bar move on, next to an APK component that finishes in two
|
|
# seconds. A card with one instant component and one slow one is how you see
|
|
# whether the per-component timings and the concurrent build really are per
|
|
# component.
|
|
#
|
|
# It takes the build mode as its one argument, so that this fixture
|
|
# exercises a component with more than one way of being built. `release`
|
|
# is deliberately the slow one, which is both what a real optimised build
|
|
# is and what makes a mode switch visible on the card: a bar that takes
|
|
# eight seconds and one that takes two.
|
|
set -eu
|
|
|
|
MODE="${1:-release}"
|
|
case "$MODE" in
|
|
release) STEPS=8 ;;
|
|
debug) STEPS=2 ;;
|
|
*)
|
|
echo "unknown build mode: $MODE (expected release or debug)" >&2
|
|
exit 2
|
|
;;
|
|
esac
|
|
|
|
i=0
|
|
while [ "$i" -lt "$STEPS" ]; do
|
|
i=$((i + 1))
|
|
echo "@@progress $i/$STEPS"
|
|
echo "==> Pretending to compile part $i of $STEPS ($MODE)"
|
|
sleep 1
|
|
done
|
|
|
|
chmod +x ./serve.sh
|
|
echo "==> Daemon ready ($MODE)"
|