Jenkins для Android сборки, с помощью Docker

[ALexhha]

После этого мы можем посмотреть начальный пароль для Jenkins

Можно просто docker logs container_id

[osipovaleks]

Да, так и есть, ваш вариант более практичный и удобный.
Добавил его в статью, спасибо!

[osipovaleks]

Да, тут только головной процесс, но в нашем случае он и единственный. Поскольку вся система строилась лишь под один проект, в котором только две таски, агенты нам были не нужны.
В целом может мы и дойдем до схемы, которая описана у вас (с автосозданием контейнеров и автоподнятием серверов), но пока нам это просто не требуется.

[Rezzet]

Жду с нетерпением вторую часть, т.к. начинает появляться примерно похожая задача и хотелось бы узнать побольше чужого опыта.

[osipovaleks]

Спасибо за ваш фидбек и доверие, я несколько дней соберу отзывы о данной статье, и надеюсь, что меня ничего не отвлечет и я сразу смогу сеть за написание второй части

[ttys]

Почему не использовать готовый дженкинс образ а этот самосбор подключать как дженкинс-агент? Тогда можно будет запустить n таких контейнеров, подключить их как агенты и билдить n количество сборок.

[osipovaleks]

Я вот тут уже описал что нам просто пока не требуются агенты, может немного позже, а вот установленный Android SDK в системе уже требуется.

[ttys]

Помоему мы говорим о разном. Я рекомендую не ставить в контейрер с дженкинсом ничего лишнего, что бы дженкинс был системой управляющей а не выполняющей. А вот все установки как раз делать на подключаемых агентах. И управлять удобно и обновлять и разные версии разных сдк, да всё что угодно можно творить с агентами.

[osipovaleks]

Ааа, я вас немного не так понял значит. Да, наверное, вы правы, возможно попробую поковырять и настроить примерно таким способом, потом может дополню статью. Спасибо за совет!

[turlir]

Интересная статья, буду ждать продолжения. Коллега сейчас занимается настройкой CI/CD. Выбрали для себя Circle CI, ресурсы наши ограничены. Если посмотреть на образ, который предлагает Circle, то видны отличия от вашего.

Вы распаковываете sdk, подтверждаете работу с лицензиями. Потом запускаете в контейнере war с дженкинсом. В такой конфигурации нельзя собрать apk. Еще нужно установить tools, platform-tools, саму платформу, опционально ndk. С учетом используемых версии, конечно же. Логично было бы изолировать окружение собственно сборки apk от дженкинса. Но когда я игрался с TeamCity, мне не удалось запустить контейнер в контейнер. С нетерпением жду продолжения.

[osipovaleks]

В такой конфигурации нельзя собрать apk. Еще нужно установить tools, platform-tools, саму платформу, опционально ndk.

Вполне можно, во время сборки нужные компоненты (кроме ndk конечно) для билда установятся сами, и вы не будете загружать систему ненужными компонентами заранее.

[turlir]

Вы правы. Я забыл про настройку android.builder.sdkDownload. Главное, что бы скачивание компонент не происходило при каждой сборке. Может образоваться очередь из сборок. Я сторонник разделять зависимости самого приложения (classpath) и sdk. В build.gradle зависимости изменяются чаще, чем версия платформы.

[osipovaleks]

я проверял, скачанное остается, и каждый раз не перекачивается если не нужно

[Mazdader]

<режим зануды>

Вы можете существенно уменьшить размер итогового образа, если вот эти две команды схлопнете в одну:

RUN apt-get update && apt-get install -y git \
wget \
...
zlib1g:i386

RUN apt-get clean && rm -rf /var/lib/apt/lists /var/cache/apt


А также вот эти 3 в одну:

RUN wget https://dl.google.com/android/repository/$sdk_tools_zip_file -P $android_home_dir -nv
RUN unzip $android_home_dir$sdk_tools_zip_file -d $android_home_dir
RUN rm $android_home_dir$sdk_tools_zip_file && chmod 777 -R $android_home_dir


Плюс это также уменьшит количество слоёв итогового образа.

</режим зануды>

А за статью спасибо — хороший гайд для тех, кто хочет начать делать правильно.

[osipovaleks]

Спасибо за совет, я попробую обязательно так сделать