Android CI builds failing on release-ios-v3.4.0 branch

[1ec5]

Android builds on Bitrise began failing on the release-ios-v3.4.0 branch (but not master), due to a Bitrise VM update, specifically bitrise-io/android#55. For example, this build from #7759 failed with:

AWS Device Farm configuration is NOT VALID

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':MapboxGLAndroidSDKWearTestApp'.
> failed to find Build Tools revision 24.0.2

As a stopgap, since we’re very close to an iOS SDK release, I put in some triggers that diverted the Android build to a no-op workflow that always passes for branches pushed by @mapbox/ios. However, the triggers are based on branch name patterns, so for example I couldn’t find a good way to exempt @incanus from Android builds. Not that that would be a great idea: we’re starting to develop on master again, which means we’ll need Android builds to run; meanwhile, we still need to keep the release-ios-v3.4.0 branch alive for v3.4.1. We need to find a way to make these builds run for real but continue to pass.

/cc @mapbox/ios @mapbox/android

[friedbunny]

The issue here is that Bitrise stopped installing the version of build tools that we specify. There are two fixes that I see:

1. Add a commit that bumps the version number to one that Bitrise installs automatically, as in [android] - update build tools to bitrise supported version #7729 on master. To avoid pulling in any potential change associated with 25.x, we could just bump to 24.0.3.
2. Install build tools 24.0.2 ourselves (via some Bitrise workflow step).

/cc @tobrun

[1ec5]

Based on this announcement, I installed the “Install missing Android tools” step right after the “Git Clone” step in the primary workflow of the Android app on bitrise.io (not in bitrise.yml). (So option 2.)

@tobrun, if this change checks out and you’d prefer to have the step in bitrise.yml, I can move it there, but I think this should be fine as a stopgap.

[1ec5]

Failed to parse build.gradle at: /bitrise/src/platform/android/MapboxGLAndroidSDK/build.gradle, error: failed to determine compileSDKVersion, error: failed to parse compileSdkVersion (Integer.parseInt(project.ANDROID_BUILD_SDK_VERSION)), error: Malformed version: Integer.parseInt(project.ANDROID_BUILD_SDK_VERSION)

[1ec5]

The step fails because this line refers to a constant in gradle.properties instead of the literal int that the step is looking for.

[1ec5]

Falling back to the third-party Android SDK Update step to install 24.0.2 explicitly.

[1ec5]

Installing 24.0.2 explicitly did the trick. Note that all builds are affected, even builds on master that don’t use 24.0.2.

[tobrun]

I was aware of the capabilities shown above but I not apply this as it increases our build times and maintenance efforts. On the other hand, I'm seeing now, it has the upside that commits in the git history will remain to work no matter what Bitrise does with future stack upgrades. I'm not opposed to this approach but have some small suggestions:

• read properties file containing the build tools version and use that as an input for the downloading only that version of the tooling (removes maintenance efforts)
• make this step part of the versioned bitrise.yml

[zugaldia]

Why not simply cherrypicking #7729 like @friedbunny suggests?

[1ec5]

read properties file containing the build tools version and use that as an input for the downloading only that version of the tooling (removes maintenance efforts)

That's what the Bitrise-provided step tried to do; however, it got tripped up trying to parse the SDK version as a literal int rather than an expression that referred to an entry in gradle.properties.

Why not simply cherrypicking #7729 like @friedbunny suggests?

Totally open to this, as long as it applies cleanly to this branch. Reopening.

[friedbunny]

Why not simply cherrypicking #7729 like @friedbunny suggests?

#7729 may require other changes, which could be a rabbit hole. It may work, but...

We should strive to keep historical commits (and current release branches, for that matter) passing on CI without additional commits. In this case, I think that means pursuing the second option I suggested: forcing the install of whichever dependencies we need and not relying on Bitrise to do so.

[1ec5]

We should strive to keep historical commits (and current release branches, for that matter) passing on CI without additional commits.

This is primarily important to facilitate bisecting. Fortunately, there’s no need to bisect Android issues on this branch, and commits on master have passed on Bitrise without interruption.

I very much liked the “Install missing Android tools” step that Bitrise provided, because it would protect future release branches against fly-by-night deployments on Bitrise’s end on a weekend. However, that step fails due to #7763 (comment). @zugaldia, do you think it would be feasible for the step itself to be patched to parse non-literals? If so, I can file a ticket upstream.

[1ec5]

Fixed in #7793 on the release-ios-v3.4.0 branch.

[1ec5]

I very much liked the “Install missing Android tools” step that Bitrise provided, because it would protect future release branches against fly-by-night deployments on Bitrise’s end on a weekend. However, that step fails due to #7763 (comment).

The Bitrise team asked us to file bitrise-steplib/steps-install-missing-android-tools#5 about this issue.