ci: manually point ANDROID_NDK_ROOT to latest supplied version#2397
ci: manually point ANDROID_NDK_ROOT to latest supplied version#2397kchibisov merged 1 commit intorust-windowing:masterfrom
Conversation
|
In general I'm fine with such solution tbqh, could change it whenever we feel like if upstream changes it again. |
It seems the symlink to `ndk-bundle` and this environment variable pointing to it have been removed to prevent the sdkmanager from failing, when finding the SDK setup to be in an "indeterminate" state. It is now up to the users themselves to install an NDK through that tool or point the right variables to a preinstalled "latest" NDK. actions/runner-images#2689 actions/runner-images#5926
MarijnS95
force-pushed
the
android-ndk-env-var
branch
from
b3de03f to
93373a3
Compare
|
Let's get this in then to unblock everyone as the CI failures are super annoying. We can remove it again when there's another sensible default). Note that we're targeting latest now instead of LTS, which is going to be NDK r25 (not sure if GH Actions venv has that yet...) until at least 2023: https://github.com/android/ndk/wiki#release-schedule. It doesn't matter anyway, we just need the compiler to build and are almost completely version-agnostic. |
|
Couldn't that be added inside |
|
@kchibisov I tried beforehand, but |
kchibisov
left a comment
kchibisov
left a comment
There was a problem hiding this comment.
That's fine. I'm not into github actions anyway.
|
For reference, looks like we can back out of this soon: actions/runner-images#5879 (comment) |
2 participants
It seems the symlink to
ndk-bundleand this environment variable pointing to it have been removed to prevent the sdkmanager from failing, when finding the SDK setup to be in an "indeterminate" state. It is now up to the users themselves to install an NDK through that tool or point the right variables to a preinstalled "latest" NDK.actions/runner-images#2689
actions/runner-images#5879
actions/runner-images#5926
Draft because I'm still waiting for confirmation that the removal of this env var is intended, instead of just pointing it to the latest LTS release without going through a symlink to match previous behaviour.