Zbiranje Android projekta v Docker vsebniku

Pri razvoju projekta za platformo Android, tudi najbolj majhnega, se prej ali slej srečamo z razvojnim okoljem. Poleg Android SDK je potrebno imeti zadnjo različico Kotlin, Gradle, platform-tools, build-tools. In če na razvojnem računalniku vse te odvisnosti reši večinoma Android Studio IDE, pa na CI/CD strežniku lahko vsako posodobitev spremeni v glavobol. Če je v spletni razvojni standard reševanja okoljskih težav Docker, zakaj ne bi poskušali rešiti podobno težavo tudi v Android razvoju...

Za tiste, ki ne vedo, kaj je Docker — če enostavno povemo, je to orodje za ustvarjanje t. i. 'kontejnerjev', kjer je vsebovana minimalna jedro operacijskega sistema in potreben nabor programske opreme, ki jo lahko uvajamo kjer koli želimo, pri tem pa ohranjamo okolje. Kaj točno bo v našem kontejnerju je določeno v Dockerfile, ki se nato sestavi v sliko, ki se lahko izvaja kjer koli in ima lastnosti idempotence.

Postopek namestitve in osnove Dockra so dobro opisani na njegovi uradni spletni strani. Zato, da malo napredujemo, smo dobili takšen 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"

Shranjeno ga bomo v mapo z našim Android projektom in nato zagnali gradnjo kontejnerja z ukazom

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

Parametri -t določa tag ali ime našega kontejnerja, ki običajno sestavljajo njegovo ime in različico. V našem primeru smo ga poimenovali android-build, v različici pa smo navedli kombinacijo različic gradle, android-sdk in platform-tools. Kasneje bo lažje poiskati potrebno sliko po imenu z uporabo take "različice".

Ko je gradnja končana, lahko našo sliko uporabljamo lokalno, lahko jo naložimo z ukazom docker push v javni ali zasebni repozitorij slik, da jo prenesemo na druge naprave.

Kot primer bomo lokalno zgradili projekt. Za to v mapi s projektom bomo izvedli ukaz

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

Poglejmo, kaj to pomeni:

docker run — ukaz za zagon slike
-rm — pomeni, da po ustavitvi kontejnerja izbriše vse, kar je bilo ustvarjeno med njegovo življenjsko dobo
-v "$PWD":/home/gradle/ — montira trenutno mapo z našim Android projektom v notranjo mapo kontejnerja /home/gradle/
-w /home/gradle — določa delovno mapo kontejnerja
android-build:5.4.1-28-27 — ime našega kontejnerja, ki smo ga zgradili
gradle assembleDebug — dejansko ekipa za gradnjo, ki gradi naš projekt

Če bo vse potekalo uspešno, boste čez nekaj sekund/minut na svojem zaslonu videli nekaj takega GRADNJA USPEŠNA v 8m 3s! V mapi app/build/output/apk bo shranjena zgrajena aplikacija.

Na podoben način lahko izvajate druge gradbene naloge gradle — preverite projekt, zaženite teste itd. Glavna prednost je, da pri potrebi po gradnji projekta na katerem koli drugem računalniku ne skrbimo za namestitev celotne okolice, zadostuje, da prenesemo potrebno podobo in zanj izvedemo gradnjo.

Kontejner ne shranjuje nobenih sprememb, in vsaka gradnja se začne iz nič, kar z ene strani zagotavlja identičnost gradnje ne glede na mesto njenega zagona, z druge strani pa je vsakokrat potrebno prenesti vse odvisnosti in ponovno prevajati celotno kodo, kar včasih lahko traja precej časa. Zato poleg običajnega 'hladnega' zagona obstaja možnost zagona gradnje s shranjevanjem t. i. 'predpomnilnika', kjer shranimo mapo ~/. gradle preprosto tako, da jo kopiramo v delovno mapo projekta, in na začetku naslednje gradnje jo vrnemo nazaj. Vse postopke kopiranja smo prenesli v ločene skripte in sama ekipa za zagon sedaj izgleda tako

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"

Na koncu se je povprečni čas gradnje projekta prepolovil (odvisno od števila odvisnosti v projektu, povprečen projekt pa se je tako začel graditi v 1 minuti namesto 5 minut).

Vse to je smiselno le, če imate svoj interni CI/CD strežnik, ki ga sami upravljate. Vendar pa danes obstaja veliko oblačnih storitev, kjer so te težave rešene in vam ni treba skrbeti, potrebne lastnosti gradnje pa lahko prav tako navedete v nastavitvah projekta.

Samo registrovani korisnici mogu učestvovati u anketi. Prijavite se, molim vas.

Ali uporabljate CI/CD sistem znotraj ali uporabljate zunanje storitve

  • Uporabljamo interni strežnik

  • Uporabljamo zunanjo storitev

  • Ne uporabljamo CI/CD

  • Kitas

42 uporabnikov je glasovalo. 16 uporabnikov se je vzdržalo.

Izvor: habr.com

Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki 🔥 Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki | ProHoster