Create mobile Docker container

[jpsim]

Installs Java 8, Android command line tools and SDK.

These are used for Envoy Mobile's CI and currently installed on every CI job run: https://github.com/envoyproxy/envoy/blob/main/mobile/ci/linux_ci_setup.sh

[lizan]

Do we want to just start the base image from the Ubuntu one? That saves time of running this script

[jpsim]

Would it actually save time though?

Because the build_container_linux mobile and build_container_linux ubuntu CI jobs run in parallel with the current setup, overall CI completes faster than if we waited for build_container_linux ubuntu to complete and then ran build_container_linux mobile pulling from what was just built.

In fact, the mobile job only builds for one architecture so it finishes faster than the ubuntu one (28 min vs 38 min), so currently this should really increase the CI wall time, assuming there's no increased queueing.

[lizan]

If you use staged build (within same Dockerfile and mark it mobile) instead of spawning multiple CI jobs, it shouldn't add extra time to CI (max of amd64 ubuntu + mobile, arm64 ubuntu).

That way the images built would share layers so it saves storage and transfer.

[phlax]

+1 re making use of docker layers

[jpsim]

Ah ok, got it! I’ll try that.

[jpsim]

The Dockerfile part seems pretty straightforward:

# envoy-build-ubuntu
FROM ubuntu:focal AS ubuntu

# Workaround for: https://issuetracker.google.com/issues/216325949
ENV CLOUDSDK_PYTHON=python3

COPY ./build_container_common.sh /
COPY ./build_container_ubuntu.sh /

RUN ./build_container_ubuntu.sh

ENV LANG en_US.utf8

# envoy-build-mobile
FROM ubuntu AS mobile
COPY ./build_container_mobile.sh /

ENV ANDROID_SDK_INSTALL_TARGET /.android
ENV ANDROID_HOME /.android/sdk
ENV ANDROID_SDK_ROOT /.android/sdk
ENV ANDROID_NDK_VERSION 21.4.7075529
ENV ANDROID_NDK_HOME /.android/sdk/ndk/21.4.7075529

RUN ./build_container_mobile.sh

And I can build the multiplatform ubuntu image with --target ubuntu and then another amd64-only build for mobile with --target mobile which will reuse the layers from the amd64 ubuntu image.

I'm struggling to find a nice way to update docker_build_linux.sh though. Especially while trying to achieve what @lizan said in his comment, to build amd64 ubuntu + mobile in parallel with arm64 ubuntu in the same CI job.

In azure-pipelines.yml I'm thinking I'd define some targets to build like this:

OS_DISTRO: ubuntu
PUSH_GCR_IMAGE: true
GCR_IMAGE_NAME: envoy-build
DOCKER_TARGETS: "ubuntu mobile"

But then I'm unclear on how I'd adjust the lines that build, tag and push in docker_build_linux.sh:

ci_log_run docker buildx build . -f "Dockerfile-${OS_DISTRO}" -t "${IMAGE_NAME}:${CONTAINER_TAG}" --platform "${BUILD_TOOLS_PLATFORMS}"

for IMAGE_TAG in "${IMAGE_TAGS[@]}"; do
  ci_log_run docker buildx build . -f "Dockerfile-${OS_DISTRO}" -t "${IMAGE_TAG}" --platform "${BUILD_TOOLS_PLATFORMS}" --push
done

[jpsim]

@lizan could you please help me get this over the finish line?

Envoy's macOS-based mobile CI jobs are pretty constrained right now because we only have 5 machines in the CI pool, so it'd be really nice to be able to migrate some of those jobs to Linux, but having the Android toolchain is a pre-requisite for that, so we can leverage RBE for building Envoy Mobile for Android.

Personally I think the PR could be merged as-is, but if you think your comment here is a blocker, I'd like to work with you to achieve that.

Thanks!

[phlax]

@jpsim i can help with this - i think it would make quite a big difference using layers, so worth the effort - certainly it should simplify things once set up

the issue i think to doing that atm is the way that the IMAGE_NAMES are set up and passed to the build script

before we do anything i think we need to add some capability for this array to carry information about build targets in the Dockerfile. Once that is done i think it will be pretty straightforward

[jpsim]

I can repro the build failure locally. Going to mark as draft until I get it building locally.

[phlax]

~should be easyfix i think - just apt-get ... install gnupg2 ~

ah - i see it wasnt using the base

[jpsim]

It's going to take a while for me to confirm this builds locally, but optimistically flipping back to ready for review since I think I fixed the issue.

[phlax]

i think this shouldnt affect the main image - and if there is a problem we can revert/fix forward - so if ci passes lets land and publish

[jpsim]

/retest

[jpsim]

Windows job failed

[phlax]

kicked