Files
irisandClaude Opus 5 4641b9ec9b A test project with two Android clients
The two-APK case had no fixture: it was verified against a scratch project
that was not kept, so the shape three recent bugs came out of was covered
only by a tempfile unit test. test-projects/two-clients is two Apk
components in one checkout, each with its own cwd and its own package --
what tdep-survey looks like, and what service-and-app cannot stand in for,
since only one of its two components produces an APK.

tablet is slow on purpose (six seconds of pretending to cross-compile,
reporting its own progress) beside a phone that builds in two, because that
is what makes ?component= visible rather than merely asserted: building one
finishes while the other has not started.

Verified live against a throwaway server rather than reasoned about.
build?component=phone ran phone alone; afterwards phone reported built and
tablet did not, which is the sibling-masking bug -- under the root-anchored
"never built at all" check the tablet would have read as current and been
refused its own first build. prepare?component=tablet then ran tablet
alone and it did build. Each component resolved its own APK under its own
directory, with its own size and mtime, so nothing reports the first
match for both.

Also corrects a sentence in that README that went stale when discovery
moved per-component: find_apks is anchored at project.join(cwd), not at
the project path. The conclusion it supports is unchanged -- every other
fixture declares no cwd, so the anchor is still the project root for them,
and building into app/ is still what keeps a stub APK from being offered
as a build of Dev Updater itself. Re-ran the check command in that section:
only the updater's own APK is reachable from the repository root.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-01 00:46:41 -04:00

46 lines
2.0 KiB
Plaintext

// A test project for Dev Updater, not a real app. See ../README.md.
//
// Two independent Android clients in one checkout, each with its own `cwd`
// and its own package. That is the shape tdep-survey has, and the one no
// other fixture here covers: `service-and-app` also has two components, but
// only one of them produces an APK, so everything that goes wrong when
// *two* do is invisible to it.
//
// Three things it exists to keep honest, all of which were real bugs:
//
// - Each component's builds are found under its own directory.
// `APK_PATTERNS` is anchored at `project.join(cwd)`; anchored at the
// project root instead, its two-level pattern reaches both clients'
// outputs and whichever matched first was reported as *every*
// component's package, size, variants and mtime. Two clients installing
// over different packages is what makes that wrong rather than merely
// redundant -- the card would check one app's installed state and
// report it as the other's.
//
// - "Never built at all" is asked per component. Because the
// root-anchored scan sees both, building either client once made the
// whole project read as "something is built here", and the other one --
// never built -- silently stopped being offered its own first build.
//
// - Building one component instead of every one. `tablet` is slow on
// purpose so that `?component=` is *visible*: pressing Update on
// `phone` finishes in about two seconds, and paying for the tablet's
// build to get it is the whole complaint that scoping exists to answer.
label: "Test: Two Clients",
components: [
Apk(
name: "phone",
// The command resolves against the project root while `cwd` says
// where to run it, so this is not `./build.sh` -- same split as
// Dev Updater's own declaration.
build: "phone/build.sh",
cwd: "phone",
),
Apk(
name: "tablet",
build: "tablet/build.sh",
cwd: "tablet",
),
],