Membangun proyek Android dalam container Docker

Saat mengembangkan proyek untuk platform Android, bahkan yang terkecil sekalipun, cepat atau lambat Anda harus berurusan dengan lingkungan pengembangan. Selain Android SDK, diperlukan versi terbaru Kotlin, Gradle, platform-tools, build-tools. Dan jika di mesin pengembang semua dependensi ini diselesaikan lebih jauh menggunakan Android Studio IDE, maka di server CI/CD, setiap pembaruan bisa membuat pusing kepala. Dan jika dalam pengembangan web, Docker telah menjadi solusi standar untuk masalah lingkungan, mengapa tidak mencoba memecahkan masalah serupa dalam pengembangan Android...

Bagi mereka yang belum tahu apa itu Docker - jika cukup sederhana, maka ini adalah alat untuk membuat apa yang disebut. "Container" yang berisi kernel OS minimum dan seperangkat perangkat lunak penting yang dapat kita terapkan di mana pun kita mau, dengan tetap menjaga lingkungan. Apa sebenarnya yang akan ada di container kita ditentukan di Dockerfile, yang kemudian dirangkai menjadi sebuah image yang dapat diluncurkan di mana saja dan memiliki sifat idempotensi.

Proses instalasi dan dasar-dasar Docker dijelaskan dengan indah di sini situs resmi. Oleh karena itu, melihat ke depan sedikit, kami memiliki 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"

Kami menyimpannya ke folder dengan proyek Android kami dan mulai membangun wadah dengan perintah

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

Parameter -t menyetel tag atau nama container kita, yang biasanya terdiri dari nama dan versinya. Dalam kasus kami, kami menyebutnya android-build dan dalam versi tersebut kami menentukan kombinasi versi gradle, android-sdk, dan platform-tools. Kedepannya kita akan lebih mudah mencari gambar yang kita perlukan berdasarkan nama dengan menggunakan “versi” tersebut.

Setelah build selesai, kita dapat menggunakan image kita secara lokal, kita dapat mendownloadnya dengan perintah dorongan buruh pelabuhan ke repositori gambar publik atau pribadi untuk mengunduhnya ke komputer lain.

Sebagai contoh, mari kita membangun proyek lokal. Untuk melakukan ini, di folder proyek, jalankan perintah

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

Mari kita cari tahu apa artinya:

buruh pelabuhan - perintah peluncuran gambar itu sendiri
-rm - berarti setelah menghentikan container, ia akan menghapus semua yang telah dibuat selama masa pakainya
-v "$PWD":/home/gradle/ - memasang folder saat ini dengan proyek Android kita ke folder internal penampung /home/gradle/
-w /home/gradle - mengatur direktori kerja wadah
android-build:5.4.1-28-27 - nama wadah yang telah kami kumpulkan
gradle merakitDebug - tim pembangun itu sendiri, yang merakit proyek kami

Jika semuanya berjalan dengan baik, maka setelah beberapa detik/menit Anda akan melihat sesuatu seperti BANGUN SUKSES dalam 8m 3s! Dan di folder app/build/output/apk akan ada aplikasi rakitan.

Demikian pula, Anda dapat melakukan tugas gradle lainnya - memeriksa proyek, menjalankan pengujian, dll. Keuntungan utamanya adalah jika kita perlu membangun proyek di mesin lain, kita tidak perlu khawatir tentang instalasi seluruh lingkungan, dan cukup mengunduh image yang diperlukan dan menjalankan build di dalamnya.

Wadah tidak menyimpan perubahan apa pun, dan setiap rakitan diluncurkan dari awal, yang, di satu sisi, menjamin identitas rakitan di mana pun ia diluncurkan, di sisi lain, setiap kali Anda harus mengunduh semua dependensi dan kompilasi semua kodenya lagi, dan ini terkadang memakan banyak waktu. Oleh karena itu, selain start "dingin" yang biasa, kami memiliki opsi untuk memulai perakitan sambil mempertahankan apa yang disebut. "cache", tempat kita menyimpan folder ~/.gradle hanya dengan menyalinnya ke folder kerja proyek, dan di awal build berikutnya kita mengembalikannya. Kami memindahkan semua prosedur penyalinan ke dalam skrip terpisah dan perintah peluncurannya sendiri mulai terlihat seperti ini

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"

Akibatnya, rata-rata waktu pembangunan proyek berkurang beberapa kali lipat (tergantung pada jumlah ketergantungan pada proyek, namun rata-rata proyek mulai dibangun dalam 1 menit, bukan 5 menit).

Semua ini dengan sendirinya hanya masuk akal jika Anda memiliki server CI/CD internal sendiri, yang Anda dukung sendiri. Namun sekarang ada banyak layanan cloud yang dapat mengatasi semua masalah ini dan Anda tidak perlu mengkhawatirkannya, dan properti build yang diperlukan juga dapat ditentukan dalam pengaturan proyek.

Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. Masuk, silakan.

Apakah Anda menyimpan sistem CI/CD Anda secara internal atau menggunakan layanan pihak ketiga

• Menggunakan server internal

• Menggunakan layanan eksternal

• Kami tidak menggunakan CI/CD

• Lain

42 pengguna memilih. 16 pengguna abstain.

Sumber: www.habr.com