Een Android-project bouwen in een Docker-container

Bij het ontwikkelen van een project voor het Android-platform, hoe klein ook, krijg je vroeg of laat te maken met de ontwikkelomgeving. Naast de Android SDK is het noodzakelijk om de nieuwste versie van Kotlin, Gradle, platform-tools, build-tools te hebben. En als op de machine van de ontwikkelaar al deze afhankelijkheden in grotere mate worden opgelost met behulp van de Android Studio IDE, dan kan op de CI / CD-server elke update hoofdpijn worden. En als Docker in webontwikkeling de standaardoplossing is geworden voor het milieuprobleem, waarom probeert u er dan niet een soortgelijk probleem mee op te lossen in Android-ontwikkeling ...

Voor degenen die niet weten wat Docker is - als het vrij eenvoudig is, dan is dit een hulpmiddel voor het maken van de zogenaamde. "Containers" die de minimale OS-kernel bevatten en de benodigde set software die we kunnen implementeren waar we maar willen, met behoud van de omgeving. Wat er precies in onze container zal zitten, wordt bepaald in de Dockerfile, die vervolgens wordt samengesteld tot een afbeelding die overal kan worden gestart en idempotentie-eigenschappen heeft.

Het installatieproces en de basisprincipes van Docker staan ​​prachtig beschreven op zijn de officiële website. Daarom, een beetje vooruitkijkend, hebben we zo'n Dockerfile

# Т.к. основным инструментом для сборки 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 het op in de map met ons Android-project en beginnen met het bouwen van de container met de opdracht

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

Parameter -t stelt de tag of naam van onze container in, die meestal bestaat uit de naam en versie. In ons geval noemden we het android-build en in de versie specificeerden we een combinatie van gradle-, android-sdk- en platform-tools-versies. In de toekomst zullen we met zo'n "versie" gemakkelijker op naam kunnen zoeken naar de afbeelding die we nodig hebben.

Nadat de build is voltooid, kunnen we onze afbeelding lokaal gebruiken, we kunnen deze downloaden met de opdracht docker push naar een openbare of privé-afbeeldingsopslagplaats om deze naar andere machines te downloaden.

Laten we als voorbeeld een lokaal project bouwen. Voer hiervoor de opdracht uit in de projectmap

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

Laten we uitzoeken wat het betekent:

koppelingsrun - de opdracht voor het starten van afbeeldingen zelf
-rm - betekent dat na het stoppen van de container alles wordt verwijderd dat tijdens zijn leven is gemaakt
-v "$PWD":/home/gradle/ - koppelt de huidige map met ons Android-project aan de interne map van de container /home/gradle/
-w /home/graad - stelt de werkmap van de container in
Android-build: 5.4.1-28-27 - de naam van onze container die we hebben opgehaald
graduele assembleDebug - het bouwteam zelf, dat ons project in elkaar zet

Als alles goed gaat, zie je na een paar seconden / minuten zoiets als SUCCESVOL BOUWEN in 8m 3s! En in de map app/build/output/apk staat een samengestelde applicatie.

Op dezelfde manier kunt u andere geleidelijke taken uitvoeren - het project controleren, tests 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 het installeren van de hele omgeving, en dat het voldoende is om de benodigde afbeelding te downloaden en de build erop uit te voeren.

De container slaat geen wijzigingen op en elke assembly wordt vanaf nul gestart, wat aan de ene kant de identiteit van de assembly garandeert, ongeacht waar deze wordt gestart, aan de andere kant elke keer dat u alle afhankelijkheden moet downloaden en compileer alle code opnieuw, en dit kan soms veel tijd kosten. Daarom hebben we naast de gebruikelijke "koude" start de mogelijkheid om de montage te starten met behoud van de zgn. "cache", waar we de map ~/.gradle opslaan door deze simpelweg naar de werkmap van het project te kopiëren, en aan het begin van de volgende build geven we deze terug. We hebben alle kopieerprocedures in afzonderlijke scripts ondergebracht en het startcommando zelf begon er zo uit te zien

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"

Als gevolg hiervan werd de gemiddelde bouwtijd van een project meerdere keren verkort (afhankelijk van het aantal afhankelijkheden van het project, maar begon het gemiddelde project dus te bouwen in 1 minuut in plaats van 5 minuten).

Dit alles op zich heeft alleen zin als u een eigen interne CI / CD-server heeft, die u zelf ondersteunt. Maar nu zijn er veel cloudservices waarin al deze problemen zijn opgelost en je er geen omkijken naar hebt, en ook de benodigde build-eigenschappen kunnen worden opgegeven in de projectinstellingen.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.

Houdt u uw CI/CD-systeem intern of gebruikt u een service van derden

• Een interne server gebruiken

• Een externe dienst gebruiken

• We gebruiken geen CI/CD

• Ander

42 gebruikers hebben gestemd. 16 gebruikers onthielden zich van stemming.

Bron: www.habr.com