Comments 9
Почему используете gradle а не gradle wrapper? Если только для того, чтобы не качать бинарник каждый раз, то как синхронизируете версию Gradle в Docker с версией в Android проекте? Руками каждый раз?
Хорошее замечание!
Однако есть нюанс. Беспощадный ру-девелоп в больших структурах (особенно родом из 90-х) как правило завязаны на определенных версиях окружения. И обновляются с новым разработчиком\команды, посему тут захардкожено.
Но соглашусь, что правильнее было бы ввести переменную (но уже в пайплайн), чтобы магия происходила в нужной директиве FROM в Dockerfile. Но тогда и Adndroid SDK нужно ставить весь, со всеми (или большинством) версиями и пакетами.
В идеальном мире - сразу в репозитории есть ряд переменных окружения, с которым работает разработчик, которые можно спарсить и подложить в Dockerfile
и итоговая апк вываливалась в какой-никакой общий доступ
Можно отправлять apk в Firebase, и все, кому надо, будут иметь доступ к только что собранной новой версии приложения.
А можно заливать apk в S3 хранилище с настроенным доступом. Вообще, как публиковать файл вариантов много.
До полноты картины автоматической сборки Android приложения, к сожалению, не описан процесс управления номером версии приложения. Как вы это делаете? Вручную, автоматически? Согласуется ли сборка с ранее опубликованными версиями? Думаю, это было бы так же интересно услышать сообществу.
История про публикацию в следующей серии =)
Приоткрою завесу тайны. Версию изменяет сам разработчик в build.gradle, Jenkins же парсит build.gradle, вытаскивает версию+номер, копирует из контейнера в хранилище. В хранилище смотрит nginx со строчкой autoindex on;
Ввиду определенного git-flow, в хранилище автоматом попадают версия на тест и версия релизная
где тут обещанный ответ на вопрос «зачем»?
Байт на потеребить колокольчик)
Шучу конечно. На самом деле ответ лежит в самой парадигме контейнеризации. Это отвязка от окружения. Я не хочу гвоздями в ноду сборки прибивать версии и параметры и не хочу привязываться к ресурсам этой ноды.
А если мы когда-нибудь корпоративно уйдем в облака, а мы это обязательно сделаем, то будет подниматься машина в облаке, отрабатывать пайплайн и удаляться. Экономия ресурсов и все такое.
Вопрос не по основной теме статьи, но все же - почему jenkins, а не что то более "модное/современное" - teamcity, gitlab ci/cd, github actions and e.t.c?
P.S.: Если ответ "исторически сложилось" то лучше не отвечать)
Когда продолжение? Вашу статью обсуждают https://www.youtube.com/watch?v=NYQLDHUGRfo&t=1576s
Как и зачем собирать Android приложение в docker контейнере