Bouwen van een Android-project in een Docker-container

Wanneer je een project voor het Android-platform ontwikkelt, hoe klein ook, moet je vroeg of laat omgaan met de ontwikkelomgeving. Naast de Android SDK is de laatste versie van Kotlin, Gradle, platform-tools en build-tools noodzakelijk. En terwijl op de machine van de ontwikkelaar al deze afhankelijkheden voornamelijk worden opgelost met behulp van de Android Studio IDE, kan elke update op de CI/CD-server een hoofdpijn worden. In de webontwikkeling is Docker de standaardoplossing voor het omgevingsprobleem, dus waarom zouden we niet proberen om een soortgelijk probleem in de Android-ontwikkeling op te lossen met behulp van Docker…

Voor degenen die niet weten wat Docker is: als we het heel simpel houden, is het een tool voor het creëren van zogenaamde 'containers' waarin de minimale kernel van het besturingssysteem en de benodigde software zijn opgenomen, die we overal kunnen implementeren terwijl we de omgeving behouden. Wat er precies in onze container komt, wordt gedefinieerd in de Dockerfile, die vervolgens wordt samengesteld in een image die overal kan worden uitgevoerd en eigenschappen van idempotentie heeft.

Het installatieproces en de basisprincipes van Docker worden uitstekend beschreven op zijn officiële website. Daarom, vooruitlopend op de zaken, hier is de Dockerfile die we hebben gekregen

# Т.к. основным инструментом для сборки Android-проектов является Gradle, 
# и по счастливому стечению обстоятельств есть официальный Docker-образ 
# мы решили за основу взять именно его с нужной нам версией Gradle
FROM gradle:5.4.1-jdk8

# Задаем переменные с локальной папкой для Android SDK и 
# версиями платформы и инструментария
ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=28 
    ANDROID_BUILD_TOOLS_VERSION=28.0.3

# Создаем папку, скачиваем туда SDK и распаковываем архив,
# который после сборки удаляем
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
# В следующих строчках мы создаем папку и текстовые файлы 
# с лицензиями. На оф. сайте Android написано что мы 
# можем копировать эти файлы с машин где вручную эти 
# лицензии подтвердили и что автоматически 
# их сгенерировать нельзя
    && mkdir "$ANDROID_HOME/licenses" || true 
    && echo "24333f8a63b6825ea9c5514f83c2829b004d1" > "$ANDROID_HOME/licenses/android-sdk-license" 
    && echo "84831b9409646a918e30573bab4c9c91346d8" > "$ANDROID_HOME/licenses/android-sdk-preview-license"    

# Запускаем обновление SDK и установку build-tools, platform-tools
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

We slaan deze op in de map met ons Android-project en starten de containerbouw met het commando

docker build -t android-build:5.4-28-27 .

Parameter -t geeft de tag of naam van onze container op, die doorgaans bestaat uit de naam en versie. In ons geval hebben we het android-build genoemd en de versie is een combinatie van de versies van gradle, android-sdk en platform-tools. Later zullen we het gemakkelijker vinden om de gewenste image op naam te zoeken met behulp van zo'n 'versie'.

Nadat de build is voltooid, kunnen we onze image lokaal gebruiken, we kunnen deze uploaden met het commando docker push naar een publieke of private image-repository om deze op andere machines te downloaden.

Als voorbeeld zullen we het project lokaal samenstellen. Hiervoor voeren we in de map met het project het commando uit

docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebug

Laten we analyseren wat het betekent:

docker run — het commando om de image te starten
-rm — betekent dat deze na het stoppen van de container alles verwijdert wat gedurende de levensduur is aangemaakt
-v "$PWD":/home/gradle/ — monteert de huidige map met ons Android-project in de interne map van de container /home/gradle/
-w /home/gradle — stelt de werkdirectory van de container in
android-build:5.4.1-28-27 — de naam van onze container die we hebben gebouwd
gradle assembleDebug — de team dat onze projectopbouw beheert

Als alles goed gaat, ziet u over een paar seconden/minuten iets dat lijkt op BOUW SUCCESVOL in 8m 3s! En in de map app/build/output/apk bevindt zich de gebouwde applicatie.

Op soortgelijke wijze kunnen andere gradle-taken worden uitgevoerd – het project controleren, testen uitvoeren, enz. Het belangrijkste voordeel is dat, als we het project op een andere machine moeten bouwen, we ons geen zorgen hoeven te maken over de installatie van de hele omgeving; het enige wat we hoeven te doen is het benodigde image downloaden en de bouw in gang zetten.

De container slaat geen wijzigingen op, en elke build start vanaf nul, wat aan de ene kant de consistentie van de build garandeert, ongeacht waar deze wordt uitgevoerd, maar aan de andere kant moeten we elke keer alle afhankelijkheden opnieuw downloaden en de hele code opnieuw compileren, wat soms aanzienlijk tijd kan kosten. Daarom hebben we behalve de gebruikelijke "koude" start ook de optie om een build te starten met behoud van de zogenaamde "cache", waarbij we de map ~/ .gradle gewoon in de werkmap van het project kopiëren en deze aan het begin van de volgende build terugplaatsen. Alle kopieprocedures hebben we in aparte scripts gegoten, waardoor ons opstartcommando er als volgt uitziet

docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 /bin/bash -c "./pre.sh; gradle assembleDebug; ./post.sh"

Uiteindelijk is de gemiddelde bouwtijd van ons project enkele keren verkort (afhankelijk van het aantal afhankelijkheden in het project, maar de gemiddelde project kan nu in 1 minuut worden gebouwd in plaats van 5 minuten).

Dit alles heeft uiteraard alleen zin als u een interne CI/CD-server heeft, waarvan u zelf de ondersteuning doet. Maar tegenwoordig zijn er veel cloudservices waarin al deze problemen zijn opgelost en u zich daar geen zorgen over hoeft te maken; de benodigde eigenschappen van de build kunnen ook in de projectinstellingen worden opgegeven.

Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. Log in, alstublieft.

Houdt u uw CI/CD-systeem intern of gebruikt u een externe service?

• Wij gebruiken een interne server

• Wij gebruiken een externe service

• Wij gebruiken geen CI/CD

• Anders

Er hebben 42 gebruikers gestemd. 16 gebruikers hebben zich onthouden.

Bron: habr.com