e936ab4646ee049a5a5bb27106aaade0a927973d
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 jaap-jan
|
1bcf422bbe |
Build the phone once per run, and stop rebuilding the toolchain image
The android job compiled everything twice. The plain `dotnet build` before the packaging step looked like a cheap check ahead of an expensive one and was neither: SignAndroidPackage depends on Build, so the packaging line compiles everything anyway — and the build above it ran with no -p:DodoChannel, which means it ran as the *release* channel. Different application id, different version, different assembly metadata; MSBuild treats a different set of global properties as a different project instance, so not one output was reused. It was a full second compile of the reference closure, producing an APK for the one channel this job must never build, thrown away unread. Measured in the toolchain image with a warm package volume, same commit: two builds 2m52 + 2m26 5m21 total one build 3m01 3m04 total Byte for byte the same artefact out of both — versionCode 203, versionName 0.0.0-alpha.0.136, dev.dodotech.dodossh.nightly. The toolchain image is now built once per Dockerfile rather than once per run. The tag is the Dockerfile's own digest and docker applies a tag only on success, so an existing tag is by construction the right image and `docker image inspect` is a sound check rather than a guess. What that trades away is the JDK from apt drifting; everything that decides what is in the image is pinned in the Dockerfile, so anything that matters changes the digest. It is a build tool, not something shipped — the image job takes the opposite trade with --pull, because what it builds is what users run. And the build job now says whether its package cache did anything. setup-dotnet's cache: true is actions/cache underneath, which needs a cache server act_runner ships and can have turned off — and when it is off it does nothing and says nothing about it. A cold restore and a perfect cache look identical from outside: both are green, and the difference is minutes. One `find` before anything writes to the folder turns that from a belief into a line in the log. It does not fail the build, because a runner without a cache server is slow rather than wrong. What is deliberately not cached: the apt installs in each job's preamble, which need the runner's image fixed rather than a workflow change and already say so; the Testcontainers pulls and the API image's layers, which the daemon already caches on a persistent runner; and the android obj/bin, which would not help — the source arrives by `docker cp` with fresh timestamps, so MSBuild rebuilds it whatever is in there. |
||
|
jaap-jan
|
a18ca56fde |
Copy the checkout into the container, because a socket is not a shared filesystem
The container started and could not see the repository: MSBUILD : error MSB1009: Project file does not exist. Switch: src/DodoSSH.Client.Android/DodoSSH.Client.Android.csproj `-v "$PWD:/build"` cannot work here. This runner is itself a container holding the host's Docker socket, so the workspace path it reports — /root/.cache/act/<hash>/… — exists in the runner and not on the daemon's host, which is where Docker resolves a bind source. It finds nothing, creates an empty directory, and mounts that. Nothing about the failure says so. Nothing earlier in this workflow would have caught it either, and that is the part worth keeping: the image job's `docker build` sends its context over the API and Testcontainers mounts nothing, so neither of the two places this repository already used Docker proves a bind mount would work. I read a working daemon as a shared filesystem, and they are not the same claim. `docker cp` goes over the same API and so does not care where the daemon lives. In with the whole checkout, .git included, since MinVer and the versionCode both read it — the repository is well under a megabyte packed. Out with the staged package. The NuGet cache becomes a named volume for the same reason: it lives on the daemon and needs no path either side has to agree on. The two container steps collapse into one, since with a copy in and a copy out there is nothing to be gained by paying for both twice, and scripts/ci-android.sh is now what runs inside — a file that can be read and executed on its own rather than a heredoc inside a workflow. Exercised locally against a real clone, every step as the job runs it: create, cp in, start --attach, cp out, parse the manifest on the outside. package: name='dev.dodotech.dodossh.nightly' versionCode='196' versionName='0.0.0-alpha.0.129' The second run took 2m25s against the first run's 8m, which is the named volume doing its job. |