Make the CI checks say what they mean, and format the workspace
Build and test / Desktop (Linux) (push) Successful in 1h23m26s
Build and test / Android (aarch64) (push) Failing after 2s
Build and test / Layer separation (push) Successful in 50s
Traceability / Requirement traces (push) Failing after 1m9s

The Android job's "Verify minimum API level" step has never verified the
minimum API level. It took the first `*.so` anywhere under the target
directory, which is a host proc-macro from debug/deps — an x86-64 object
built by the runner's gcc, whose .comment section cannot mention Android
and so can never contradict the expected value. It now reads the artifact
under the target triple, compares against MIN_API parsed from the
Dockerfile rather than a second copy of the number, and fails on a
mismatch. Both sides are checked non-empty first: two failed parses would
otherwise compare equal and pass, which is the same silent success in a
new costume.

The Android image installs one SDK package per layer and keeps the
output. sdkmanager is a JVM program that aborts when it cannot get memory,
and the single `> /dev/null` step reported that as a bare "exit code 134"
while a retry re-downloaded everything that had already succeeded.

tools/ci-local.sh runs all four jobs — desktop, android, layering,
traceability — against the host toolchain, which is pinned to the same
1.92.0 CI installs. Its matrix check compares regeneration against the
working tree rather than against HEAD: CI starts from a clean checkout, so
git's answer is the right one there and reports every local run stale here.

The rest is rustfmt across the workspace, and the clippy findings that
surfaced once it did: manual_contains in dr-thumbs and collections_ui, a
map iterated as pairs for its keys, an index loop over a slice, and two
runtime assertions on a constant now made at compile time.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-16 12:02:51 +02:00
co-authored by Claude Opus 5
parent 94a2686dcb
commit 03326242a1
31 changed files with 927 additions and 387 deletions
+21 -7
View File
@@ -77,13 +77,27 @@ RUN mkdir -p ${ANDROID_HOME}/cmdline-tools \
&& mv ${ANDROID_HOME}/cmdline-tools/cmdline-tools ${ANDROID_HOME}/cmdline-tools/latest \
&& rm /tmp/tools.zip
RUN yes | sdkmanager --licenses > /dev/null 2>&1 || true \
&& sdkmanager --install \
"platform-tools" \
"platforms;android-${ANDROID_API}" \
"build-tools;${BUILD_TOOLS}" \
"ndk;${NDK_VERSION}" \
> /dev/null
# One package per layer, and the output kept.
#
# Both halves are scar tissue from the same build. sdkmanager is a JVM program
# that aborts (SIGABRT, exit 134) when it cannot get memory — which it will on a
# loaded machine, since the NDK alone unpacks some 4.5 GB. With the whole
# install in one `> /dev/null` step, that surfaced as "exit code 134" and
# nothing else, and a retry re-downloaded the three packages that had already
# succeeded before reaching the one that had not.
#
# pipefail matters here: without it the `tr | tail` pipeline would report the
# exit status of `tail`, which is exactly the masking this step is undoing.
# Progress bars are carriage returns, hence the tr — the tail keeps the summary
# without the several thousand redraws.
SHELL ["/bin/bash", "-o", "pipefail", "-c"]
RUN yes | sdkmanager --licenses > /dev/null 2>&1 || true
RUN sdkmanager --install "platform-tools" 2>&1 | tr '\r' '\n' | tail -3
RUN sdkmanager --install "platforms;android-${ANDROID_API}" 2>&1 | tr '\r' '\n' | tail -3
RUN sdkmanager --install "build-tools;${BUILD_TOOLS}" 2>&1 | tr '\r' '\n' | tail -3
RUN sdkmanager --install "ndk;${NDK_VERSION}" 2>&1 | tr '\r' '\n' | tail -3
ENV ANDROID_NDK_HOME=${ANDROID_HOME}/ndk/${NDK_VERSION} \
ANDROID_NDK_ROOT=${ANDROID_HOME}/ndk/${NDK_VERSION}