Android build often failing at the "Running Gradle" step

[blitzclock]

I’ve recently been having issues when building my app, but only with the Android build and only about half the time. I’m not sure I can do anything to fix the issue since:

• My app builds fine when I trigger a build from my local machine, rather than my CI even though I run the exact same command I copy/paste from my CI’s output.
• iOS never has issues building.
• Local dev works flawlessly.

Here’s a screenshot of the error in the Expo.io UI:

Diagnostics:

  Expo CLI 4.1.6 environment info:
    System:
      OS: Linux 5.8 Debian GNU/Linux 9 (stretch) 9 (stretch)
      Shell: 4.4.12 - /bin/bash
    Binaries:
      Node: 15.6.0 - /tmp/yarn--1614016293309-0.7788894182410655/node
      Yarn: 1.22.5 - /tmp/yarn--1614016293309-0.7788894182410655/yarn
      npm: 7.4.0 - /usr/local/bin/npm
    npmPackages:
      @expo/webpack-config: ^0.12.52 => 0.12.52 
      expo: ^40.0.0 => 40.0.0 
      react: 16.13.1 => 16.13.1 
      react-dom: 16.13.1 => 16.13.1 
      react-native: https://github.com/expo/react-native/archive/sdk-40.0.1.tar.gz => 0.63.2 
      react-native-web: ~0.13.12 => 0.13.18 
      react-navigation: ^4.0.10 => 4.0.10 
    Expo Workflow: managed

Any help would be greatly appreciated. Thank you!

[blitzclock]

Actually, I ran two more builds since this post and it seems like the Android build fails all the time when launched from my CI server.

The error message does not help me to figure out what’s going on though.

[notbrent]

can you share a link to your build, please? only members of your team and expo employees will be able to actually access the page

[blitzclock]

Sure thing: https://expo.io/accounts/blitzclock/builds/fb7d12a6-a18b-4963-95b1-6a022f779239

And the logs (that I can see anyway) are here: https://expo.io/accounts/blitzclock/builds/fb7d12a6-a18b-4963-95b1-6a022f779239/logs

[blitzclock]

Here’s a build that worked: https://expo.io/accounts/blitzclock/builds/0b55d8a7-3164-47b4-9910-e7ceed11560e.

Same command was ran, but from my local machine. I figure it might help in understanding what’s going on.

[notbrent]

that’s odd. what does your ci server do differently than your local machine?

[blitzclock]

Nothing that I can see. The CI is Gitlab and the job runs in a Docker image (node:15.6.0) same as my local. The Expo CLI is running from the local node_modules on both machine (via yarn expo build:android).

The only difference I can see is that we add gosu in our local node image to handle file permissions during local development. Here’s the Dockerfile and entrypoint:

FROM node:15.6.0

# gosu is used to match the container's user with the host's
COPY --from=gosu/alpine /usr/local/bin/gosu /usr/local/bin/gosu

COPY entrypoint.sh /usr/local/bin/entrypoint.sh
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

#!/bin/bash
set -e

cwd=$(pwd)
user_id=$(stat -c "%u" "$cwd")

sed -ie "s/$(id -u node)/$user_id/g" /etc/passwd

if [ "${1#-}" != "${1}" ] || [ -z "$(command -v "${1}")" ]; then
  set -- node "$@"
fi

exec gosu "$user_id" "$@"

Is there anything I could run on both machines that could help with figuring out what’s happening?

[notbrent]

i’m having a hard time narrowing down what would be causing this, and it looks like it has only happened to you and one other user (with ci in their username).

could you try building with the expo build:android with the --no-publish flag on ci? that will help us narrow down if it is somehow related to the publishing step

[blitzclock]

The build is still failing: https://expo.io/accounts/blitzclock/builds/2ce9c32c-658a-4584-a236-c050de0b5b10/logs

I have confirmed a few things while doing that build with --no-publish set.

• Both versions of Yarn used on my local and my CI and the exact same, 1.22.5.
• Both versions of NodeJS are the exact same v15.6.0.
• Both run the locally installed Expo CLI 4.1.6.

Here are the results of the build command in my CI, which resulted in the above log:

$ yarn expo build:android --non-interactive -t app-bundle --no-publish --no-wait --release-channel=$RELEASE_CHANNEL
yarn run v1.22.10
$ /Users/Guyllaume/builds/_XuzpB5n/0/majisti-apps/blitzclock/mobile-app/node_modules/.bin/expo build:android --non-interactive -t app-bundle --no-publish --no-wait --release-channel=internal
Opening `/dev/tty` failed (6): Device not configured
┌─────────────────────────────────────────────────────────────────────────┐
│                                                                         │
│   There is a new version of expo-cli available (4.2.1).                 │
│   You are currently using expo-cli 4.1.6                                │
│   Install expo-cli globally using the package manager of your choice;   │
│   for example: `npm install -g expo-cli` to get the latest version      │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
- Making sure project is set up correctly...
[10:46:38] Checking if there is a build in progress...
[10:46:39] Accessing credentials for blitzclock in project blitzclock
[10:46:39] Looking for releases...
[10:46:39] Using existing release on channel "internal":
publicationId: 1f625395-dc5e-41be-abb2-e74c7ef34f9d
  publishedTime: 2021-02-26T14:24:37.562Z
[10:46:39] Checking if this build already exists...
[10:46:39] Build started, it may take a few minutes to complete.
[10:46:39] You can check the queue length at https://expo.io/turtle-status
[10:46:39] You can monitor the build at
 https://expo.io/accounts/blitzclock/builds/2ce9c32c-658a-4584-a236-c050de0b5b10
[10:46:39] Alternatively, run `expo build:status` to monitor it from the command line.
Done in 13.77s.

[wkozyra]

builds that are failing have version code outside of range of 32 bit integer (eg 20210226124), builds that work have values 10 times smaller that are just on the edge of that range. We seem to generate build.gradle correctly, but it seems gradle does not support values like that.

You need to use lower numbers

[blitzclock]

Wow, I can’t believe I didn’t realise this might be the issue… I’ll see if I can’t review our versioning strategy to prevent this kind of error.

I was going with a “YYYY.MM.DD.GitlabBuildNumber” strategy to automatically handle guaranteed unique versions for each build, without having to bother with semver. Android requiring build number to be actual integer I end up with these very large integer.

I’ll validate the solution and close this once done. Thanks.

[blitzclock]

The version code was a good thought, but it seems it was not the issue. My latest build still failed: https://expo.io/accounts/blitzclock/builds/6b7a5b1d-9f01-4097-954d-d69a1dbb06ef/logs.

This build cannot have a version code bigger than 999999999. I need to add some more logging, but the above build should have a version that ranges between 210309001 and 210309999 which is lower than the maximum of 2147483647.

Edit: Actually, it seems like the maximum value for the version code is 2100000000, not 2147483647. Still, the version strategy I use generates version way under this maximum.

Edit: Ignore that, looking though the manifest of the build, I can see the build number is still way too large. Seems like my CI generates version codes differently than my machine somehow. I’ll dig into it, but for this topic, the issue is solved. Thanks a lot for the help.

[blitzclock]

To validate the version code issue, I sent this build manually (by running on my machine rather than my CI) https://expo.io/accounts/blitzclock/builds/93ab8021-4a91-4885-8103-c9c4175008f6/logs. The strategy to generate a version code is the same as the failed build in my previous post. More specifically, it’s 210309345 and the build worked.

Edit: Nope. See above.