Skip to content

Resolve sdkmanager by its known layouts, and say what is there when it is not #526

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
bernardladenthin merged 1 commit into from
Oct 11, 2026
Merged

Resolve sdkmanager by its known layouts, and say what is there when it is not #526

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 42 additions & 4 deletions .github/workflows/publish.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1188,12 +1188,31 @@ jobs:
if [ -z "$SDKMANAGER" ]; then
for root in "${ANDROID_HOME:-}" "${ANDROID_SDK_ROOT:-}" /usr/local/lib/android/sdk; do
[ -n "$root" ] || continue
candidate="$(find "$root/cmdline-tools" -maxdepth 2 -name sdkmanager -type f 2>/dev/null | sort | tail -1)"
if [ -n "$candidate" ]; then SDKMANAGER="$candidate"; break; fi
# Keep the first root that answers: the inner break leaves only the inner
# loop, so without this a later root would overwrite the found path. Written
# as an if rather than "test && break", which under set -e would end the
# step the moment the test is false.
if [ -n "$SDKMANAGER" ]; then break; fi
# The known layouts, newest first, rather than one find: cmdline-tools/<version>/bin
# sits three levels below cmdline-tools, which an earlier -maxdepth 2 never reached --
# it stopped at the bin directory and reported 'not found' for a file that was there.
for candidate in "$root/cmdline-tools/latest/bin/sdkmanager" "$root/cmdline-tools"/*/bin/sdkmanager "$root/tools/bin/sdkmanager"; do
if [ -x "$candidate" ]; then SDKMANAGER="$candidate"; break; fi
done
done
fi
if [ -z "$SDKMANAGER" ]; then
echo "::error::sdkmanager not found -- looked on PATH and under ANDROID_HOME='${ANDROID_HOME:-}', ANDROID_SDK_ROOT='${ANDROID_SDK_ROOT:-}' and /usr/local/lib/android/sdk. This is a runner-image change, not a download problem."
# Name what IS there. The first version said only where it had looked, which left
# the reader to guess whether the directory, the version subdirectory or the file
# was missing -- three causes behind one message.
for root in "${ANDROID_HOME:-}" "${ANDROID_SDK_ROOT:-}" /usr/local/lib/android/sdk; do
[ -n "$root" ] || continue
echo "contents of ${root}:"
ls -la "$root" 2>&1 | sed "s/^/ /" || true
echo "contents of ${root}/cmdline-tools:"
ls -la "$root/cmdline-tools" 2>&1 | sed "s/^/ /" || true
done
exit 1
fi
echo "using sdkmanager: $SDKMANAGER"
Expand Down Expand Up @@ -1378,12 +1397,31 @@ jobs:
if [ -z "$SDKMANAGER" ]; then
for root in "${ANDROID_HOME:-}" "${ANDROID_SDK_ROOT:-}" /usr/local/lib/android/sdk; do
[ -n "$root" ] || continue
candidate="$(find "$root/cmdline-tools" -maxdepth 2 -name sdkmanager -type f 2>/dev/null | sort | tail -1)"
if [ -n "$candidate" ]; then SDKMANAGER="$candidate"; break; fi
# Keep the first root that answers: the inner break leaves only the inner
# loop, so without this a later root would overwrite the found path. Written
# as an if rather than "test && break", which under set -e would end the
# step the moment the test is false.
if [ -n "$SDKMANAGER" ]; then break; fi
# The known layouts, newest first, rather than one find: cmdline-tools/<version>/bin
# sits three levels below cmdline-tools, which an earlier -maxdepth 2 never reached --
# it stopped at the bin directory and reported 'not found' for a file that was there.
for candidate in "$root/cmdline-tools/latest/bin/sdkmanager" "$root/cmdline-tools"/*/bin/sdkmanager "$root/tools/bin/sdkmanager"; do
if [ -x "$candidate" ]; then SDKMANAGER="$candidate"; break; fi
done
done
fi
if [ -z "$SDKMANAGER" ]; then
echo "::error::sdkmanager not found -- looked on PATH and under ANDROID_HOME='${ANDROID_HOME:-}', ANDROID_SDK_ROOT='${ANDROID_SDK_ROOT:-}' and /usr/local/lib/android/sdk. This is a runner-image change, not a download problem."
# Name what IS there. The first version said only where it had looked, which left
# the reader to guess whether the directory, the version subdirectory or the file
# was missing -- three causes behind one message.
for root in "${ANDROID_HOME:-}" "${ANDROID_SDK_ROOT:-}" /usr/local/lib/android/sdk; do
[ -n "$root" ] || continue
echo "contents of ${root}:"
ls -la "$root" 2>&1 | sed "s/^/ /" || true
echo "contents of ${root}/cmdline-tools:"
ls -la "$root/cmdline-tools" 2>&1 | sed "s/^/ /" || true
done
exit 1
fi
echo "using sdkmanager: $SDKMANAGER"
Expand Down
27 changes: 21 additions & 6 deletions TODO.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1046,12 +1046,27 @@ for everything else.
that was only occasionally flaky into one that is always red** (runs 38146809329, 38148401395,
38149667195), and the misleading message is what kept that invisible: a reader sees a download
problem at Google and waits for it to pass.
Fixed by resolving the command (PATH, then `$ANDROID_HOME`, `$ANDROID_SDK_ROOT` and the image's
`/usr/local/lib/android/sdk`, newest `cmdline-tools` version last) and by **keeping the two failure
modes apart**: "not found" now says it is a runner-image change and not a download problem. Both
copies of the step are fixed identically. **Still to verify in CI** -- the emulator jobs have not
been green since the step was added, so the thing the step was built to guard against (the corrupt
archive of run 38069595101) also remains unproven.
Fixed in two steps, and the first one was wrong in a way the second could only find *because* it
was wrong. The first (#519) kept the two failure modes apart -- "not found" says it is a
runner-image change and not a download problem -- and resolved the command with
`find "$root/cmdline-tools" -maxdepth 2`. Run 38164077038 then reported, in one line,
`sdkmanager not found -- looked ... ANDROID_HOME='/usr/local/lib/android/sdk'`: the directory is
there, and the file sits at `cmdline-tools/latest/bin/sdkmanager`, which is **three** levels below
`cmdline-tools` -- the search stopped at the `bin` directory. An off-by-one, mine; what the
message rewrite bought was seeing it at a glance instead of suspecting Google again.
The second (#526) drops the find for the three known layouts in order (`cmdline-tools/latest/bin`,
`cmdline-tools/<version>/bin`, the old `tools/bin`), guards the outer loop so a later root cannot
overwrite the found path, and -- the part the first version lacked -- **lists what is actually
under each root** when nothing is found, because naming only the places searched leaves three
causes (missing directory, missing version subdirectory, missing file) behind one message.
Validated against five faked layouts locally, including the failure case. **Still to verify in CI**
-- the emulator jobs have not been green since the step was added, so the thing it was built to
guard against (the corrupt archive of run 38069595101) also remains unproven.
One trap worth keeping for whoever tests such a step locally: on this Windows checkout `chmod +x`
does not stick on a plain file (`ls -l` still shows `rw-r--r--`), so `[ -x ]` answers *false* and
every probe "failed" until the fixtures were given a `#!/bin/sh` line. The first run of that probe
reported all five layouts broken, including the one that demonstrably works in CI -- the harness,
not the logic.
- **Everything behind `package` has never run on the modular natives.** Run 38069595101 skipped
`package` (it `needs` the Windows clang test job, red with the AMX crash); this branch's run
38112603436 reaches it and fails on the Windows OpenVINO module jar (the blocker at the top of
Expand Down
Loading