[Разработка под Android, DevOps] Прокачиваем Android проект с GitHub Actions. Часть 1
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет!Это пост для тех, кто заинтересовался возможностями GitHub Actions, но никогда не имел опыта реальной настройки build-систем. Примеры будут полезны как для прокачки собственного pet-проекта, так и для понимания, как настраивается CI/CD, если по работе нет связанных с этим задач.Что будет рассмотрено:
- Основные понятия для построения CI/CD на GitHub Actions.
- Настроим работающий workflow который запускает Unit-тесты при создании pull request.
- Добавим бейджики со статусом созданных workflow в репозиторий.
- Настроим работающий workflow для сборки релизных артефактов APK и AAB.
- Научимся безопасно подписывать ключом релизный APK.
GitHub Actions был выбран для примеров, потому что позволяет не углубляясь в инфраструктурные сложности с развёртыванием своего собственного CI-сервера буквально за день собрать работающий пайплайн для прогона тестов, подписи приложения и даже загрузки в Google Play. Кроме того, у GitHub Actions полная интеграция с GitHub, очень легко взаимодействовать с репозиторием. Для открытых репозиториев услуга бесплатная, для закрытых предусмотрены разные тарифные планы.Но главное преимущество GitHub Actions состоит в возможности переиспользовать готовые блоки бизнес-логики (actions), причём не только свои собственные. На большинство самых распространённых задач уже скорее всего есть свой Action, который вы можете включить в свой пайплайн! Какие экшены уже написаны участниками сообщества, можно посмотреть на https://github.com/marketplace?type=actionsПримеры будут настраиваться на самом простом проекте с одной пустой Activity из шаблонов Android Studio и на новом пустом репозитории в GitHub.Общие слова про Github ActionsЕсли кто-то представляет себе, как собирают автомобили на заводах, это неплохая иллюстрация к тому, чем вообще занимается CI/CD.Пайплайн можно представить себе как конвейер на заводе, по которому непрерывно продвигается по стадиям подготовки релиза код.На вход конвейера попадает коммит в репозиторий или пулл-реквест. Потом код попадает на участок сборки приложения, далее запускаются unit и UI-тесты. Если тесты прошли успешно, можно смело двигаться дальше по конвейеру, например, выложить в раздел релизов артефакт для истории версий.Основные понятияВот так по блокам можно представить, как структурирован workflow в Github Actions.
RunnerЭто развёрнутый в облаке от GitHub или self-hosted сервер с настроенным окружением и который может запускать workflow внутри себя.WorkflowЭто независимый процесс, автоматически запускаемый на GitHub Actions в отдельном контейнере по получению Event. Каждый workflow описывается отдельным YAML-файлом.Состоит из более мелких структурных единиц исполнения - Jobs.JobСоставная часть workflow, в свою очередь состоит из отдельных шагов Steps. Jobs могут быть настроены на параллельное и последовательное выполнение.StepЕще более мелкая единица исполнения скрипта, состоит из набора команд или действий.ActionsСамая маленькая структурная единица исполнения скрипта workflow. Action может делать в принципе всё что угодно, например, проставлять теги с версией приложения в Git или отправлять собранный AAB в Google Play.Можно писать как собственный Action, так и пользоваться готовыми. Action по сути выступает наравне с другими командами внутри Step.Самые распространённые Action - это checkout на коммит и установка Java-окружения. По умолчанию, если специально не встать на нужный коммит, Job ничего не знает о проекте, из которого он запущен.Пример ниже подготавливает окружение, а Uses указывает скрипту, что необходимо дождаться их окончания, прежде чем выполняться дальше.
- uses: actions/checkout@v1
- uses: actions/setup-java@v1
EventВнутренние или внешние события, которые запускают workflow. Commit, pull request, comment, tag - все эти события могут быть использованы в ваших скриптах как триггер для старта каких-то действий. Еще workflow может быть настроен на ручной запуск (https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch/) и запуск по cron расписанию (https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#scheduled-events)Hello, world!Всё, что связано в GitHub Actions, располагается на вкладке Actions в репозитории.
При создании нового workflow GitHub пытается проанализировать содержимое репозитория и предлагает шаблон на выбор. На самые популярные сценарии сборки и деплоя можно найти заготовки.Все workflow конфигурируются через файлы в формате YAML, это фактически стандарт для CI/CD-систем.Чтобы GitHub Actions начала выполнять таски, необходимо положить их в определённым образом названную директорию в корне проекта github/workflows.Добавлять и редактировать конфиги можно как в Android Studio, так и в самом GitHub на вкладке Actions. Так и поступим.
Сами конфиги в YAML можно называть как угодно, но лучше давать осмысленные имена для того, чтобы позднее самому понимать, что именно тут настроено.GitHub сразу же подставляет самый простой скрипт, который делает checkout на новый коммит, выводит в консоль несколько строк и заканчивает работу. Что-то ещё проще придумать сложно, но даже в этом примере есть что посмотреть.
# This is a basic workflow to help you get started with Actions
name: CI
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the develop branch
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world!
# Runs a set of commands using the runners shell
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
Сделать коммит с новым скриптом можно прямо из веб-интерфейса GitHub.
Но когда этот workflow будет отрабатывать? Ведь мы раньше упоминали, что в GitHub Actions все workflow запускаются не сами по себе, а только при получении того event’а, который прописан в самом yml-скрипте.
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
Тут видно, что наш тестовый скрипт будет выполняться для любых коммитов и пулл-реквестов в ветку main.Стойте, так мы ведь только что сделали коммит с новым hello_world.yml, получается, он уже должен был сработать? Совершенно верно, можно прямо сейчас зайти в раздел actions и посмотреть результат работы скрипта.
Уже неплохо! Обычно после первого знакомства с новой технологией сразу хочется усложнить свой hello world и заставить его делать хоть что-то полезное, кроме вывода текста в консоль.Запуск unit-тестов на каждый pull request в mainПервый YAML-скрипт мы создавали в веб-интерфейсе GitHub, теперь сделаем то же самое в Android Studio.Чтобы увидеть директорию с YAML-файлами, нужно переключить режим просмотра на “Project” (если вдруг у вас был выбран режим “Android”).Находим директорию workflows и создаём новый файл с типом YML. Назовём его, к примеру, run_unit_tests.yml.Пока что всё, что мы хотим от скрипта, - это запускать unit-тесты на каждом pull request в ветку main. Можно скопировать целиком код из примера, всё должно работать. Если GitHub покажет, что в YAML ошибка, то проверить в первую очередь стоит правильность форматирования и количество отступов у блоков, так как формат чувствителен к этому.
name: PR_unit_tests
on:
pull_request:
branches:
- 'main'
jobs:
Unit-test:
name: Run unit tests on PR in main
runs-on: ubuntu-20.04
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
with: {java-version: 1.8}
- name: Run unit tests
run: ./gradlew test
actions/checkout@v2 и actions/setup-java@v1 подготавливают окружение для запуска тестов, первый выкачивает репозиторий и встаёт на нужный коммит, а второй устанавливает Java 8 - окружение. Это те самые Actions, которые даже упоминаются в названии, самые маленькие исполняемые единицы workflow. Можно рассматривать их как подключаемые к вашему workflow внешние библиотеки. Если интересно, что именно делают эти Actions, переходите по ссылкам https://github.com/actions/checkout https://github.com/actions/setup-java run: ./gradlew test запускает тесты с помощью gradle wrapper.Запускать можно всё то же самое, что и в консоли, доступны все команды shell. Можно ещё написать свой собственный shell-скрипт и просто запустить его в этом месте, например, так: “run: ./run_unit_tests.sh”Тут открывается простор для автоматизации всего что только можно. Если раньше вы никогда самостоятельно не писали shell-скрипты, рекомендую прочитать книгу “The Linux Command Line: a Complete introduction” от William Shotts, очень хорошее введение в shell-автоматизацию.Готово! Создаем любой пулл-реквест в ветку main и смотрим во вкладке Actions, что получилось.
Я специально испортил один unit-тест, чтобы показать ещё одну базовую настройку вашего CI/CD-пайплайна - запрет на merge в ветку main c поломанными тестами. Всё логично: если ваш новый коммит что-то поломает в бизнес-логике приложения, то автоматика не даст сделать по ошибке merge. Или по крайней мере предупредит о проблеме.Настраивается это очень просто: заходим в Settings репозитория, вводим в “Branch name pattern” паттерн для тех веток, для которых хотим создать новое правило безопасности. В нашем случае можно ввести “main”. Далее проставляем галочки в нужных условиях правила и сохраняем.
Всё готово, вы только что создали своё первое правило для merge в своем репозитории. Смотрим теперь, как поведёт себя автоматика с pull-request, в котором поломаны тесты.
Работает! При желании можно запретить merge с проблемами даже для администраторов, там же в настройках merge protection rule.Если хочется прямо сейчас самостоятельно что-то настроить, то вот несложное задание. Gradle task test, который мы запускали, генерит небольшой отчет по результатам запуска unit-тестов, всё лежит в app/build/reports/tests/testDebugUnitTest/
Попробуйте самостоятельно добавить после шага Run unit tests ещё один шаг, который выкачивает отчет по тестированию.Подсказка - использовать actions/upload-artifact@v2На этом часть про запуск unit-тестов закончена, дальше настроим сборку и подпись релизного APK.Задачу сформулируем так: подготавливать нам APK и AAB и подписывать ключом из keystore. Причём сборку мы будем запускать только на pull request в main из веток с именем, начинающимся с release/Задача стала чуть сложнее, поэтому будем рассматривать ее по шагам.Шаг 1. Собираем APK и AAB. Пока не подписываем
name: Test_and_build_artifacts_on_release
on:
pull_request:
branches:
- 'main'
jobs:
build_apk_aab:
if: startsWith(github.head_ref, 'release/') == true
name: Build release artifacts
runs-on: ubuntu-20.04
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
with: {java-version: 1.8}
- name: Build release APK and AAB after test
run: |
./gradlew test
./gradlew assembleRelease
./gradlew bundleRelease
- name: Upload APK
uses: actions/upload-artifact@v2
with:
name: app-release.apk
path: app/build/outputs/apk/release/app-release-unsigned.apk
- name: Upload AAB Bundle
uses: actions/upload-artifact@v2
with:
name: app-release.aab
path: app/build/outputs/bundle/release/app-release.aab
Вот эта строчка является проверкой имени ветки, из которой создается pull request, и, если условие выполняется, workflow продолжается. Мы ведь решили запускать сборку и подпись только для релизных веток.
if: startsWith(github.head_ref, 'release/') == true
Этот блок команд запускает, используя Gradle wrapper, тесты, а затем сборку APK и AAB. Обратите внимание, вертикальная черта позволяет запускать несколько shell-команд в одном блоке run.
run: |
./gradlew test
./gradlew assembleRelease --stacktrace
./gradlew bundleRelease
Следующий шаг достанет после сборки APK и оставит его в виде артефакта в GItHub. Если этого не сделать, все временные файлы будут удалены после завершения workflow. Стоит обратить внимание, что APK остаётся неподписанным, мы просто не сконфигурировали пока ничего для этого. В таком виде APK его ещё нельзя выложить в Google Play, как настроить автоматическое подписание, будет рассказано дальше.Подробнее про Action upload-artifact@v2 можно посмотреть тут. Основное, что может этот Action, - это выкачать файл по имени либо целиком директорию и упаковать в zip-архив.
- name: Upload APK
uses: actions/upload-artifact@v2
with:
name: app-release.apk
path: app/build/outputs/apk/release/app-release-unsigned.apk
Аналогичным образом достаем и AAB-файл.
Шаг 2. Подписываем APKСначала немного теории, как и зачем вообще подписывать APK.Цифровая подпись необходима для того, чтобы Google Play мог идентифицировать разработчика и в дальнейшем только он мог обновлять приложение, это крайне важная вещь в процессе размещения проекта в магазине приложений. В целях безопасности цифровая подпись хранится не в открытом виде, а в специальном хранилище типа key value - файле с расширением jks или keystore. Сам файл хранилища стоит держать в надёжном месте, это, можно сказать, паспорт вашего приложения.Как создать keystoreЕсли вы уже выложили своё приложение в Google Play, то ключ у вас точно есть. Если же нет - ниже простая инструкция.Вариантов два - создать через консоль или через IDE.
- Консоль
$ keytool -genkey -v -keystore my_app_keystore.keystore -alias app_sign_key -keyalg RSA -keysize 2048 -validity 10000
my_app_keystore.keystore - это название самого хранилища, которое мы создаем.app_sign_key - название ключа, по которому мы будем доставать наш секретный ключ.10000 - время жизни ключа в днях (примерно 27 лет).Вводим пароль на хранилище, пароль на ключ и потом по желанию метаданные о владельце. Всё, хранилище готово, можно пользоваться.2) В Android StudioВ меню студии заходим в Build -> Generate Signed Bundle / APK.Дальше Next -> Create New и вводим всё то же самое: пароли, имя хранилища и имя ключа в хранилище.
Чтобы собранный APK успешно подписать ключом из хранилища, необходимо этот самый ключ достать по имени (key alias), предварительно получив доступ через пароль к хранилищу (store password) и пароль непосредственно к ключу (key password). Это происходит в рамках специального Gradle task, всё будет далее автоматизировано.Дополнительная информацияhttps://developer.android.com/studio/build/building-cmdline#gradle_signinghttps://developer.android.com/studio/publish/app-signing#secure-shared-keystorehttps://developer.android.com/studio/publish/app-signing#sign-autoИ тут возникает два вопроса.
- Где хранить пароли от хранилища, не в открытом же виде прописывать их в конфигах?
- Как и куда выкладывать само хранилище ключей для открытого проекта?
Для хранения секретных данных, например, таких как идентификаторы приложения в Facebook, VK или Firebase, сервис GitHub предлагает механизм Secrets. Особенность механизма хранения в том, что после сохранения ключа уже невозможно будет просто так зайти и посмотреть его. Только ввести новый, полностью удалить или использовать “как есть” в коде по имени. В логах секретные данные скрываются за звёздочками.
После добавления секретов к ним можно обращаться через специальный синтаксис прямо из YAML-скриптов. Например, вот так мы запишем EXAMPLE_API_KEY_1 в переменную окружения и затем в Gradle-скрипте, которому она понадобится, достанем её через System.getenv('EXAMPLE_API_KEY_1')
env:
API_KEY: ${{ secrets.EXAMPLE_API_KEY }}
Отлично, часть проблемы решена, но куда положить само хранилище?Можно в сам проект, конечно, но раз мы тут занимаемся автоматизацией процесса сборки и подписи, то как насчёт отдельного приватного репозитория чисто под хранилище? После настройки можно будет по шаблону подписывать все ваши приложения из этого хранилища.Ничего кроме хранилища мы не собираемся помещать в новый приватный репозиторий. Мы будем клонировать его прямо в наш основной репозиторий в директорию app/keystore перед подписью APK-файла и доставать из него ключ с помощью паролей, который поместим в секцию Secrets в основном репозитории. Вот так будет выглядеть структура проекта на CI после клонирования репозитория с ключом в проект с основным проектом.
Звучит не очень сложно, смотрим, как такое настроить в GitHub Actions.
- Создаем приватный репозиторий и помещаем туда только хранилище ключей.
- Генерируем Personal access token для доступа к приватному репозиторию с хранилищем. Делаем всё по этой инструкции и не забываем сразу же скопировать сгенерированный токен. Этот токен будет играть роль логина и пароля при клонировании репозитория с хранилищем. Важно не запутаться и генерировать токен именно в том аккаунте, где расположен наш приватный репозиторий.
- Добавляем Personal access token из предыдущего шага в секреты основного проекта под любым именем, например KEYSTORE_ACCESS_TOKEN.
- Добавляем все пароли и key_alias от хранилища. Добавляем название аккаунта и имя приватного репозитория туда же в секреты основного проекта через слеш, что-то вроде “another-account/secret-repo”. Это понадобится нам дальше, когда будем клонировать репозиторий с ключом в YAML-скрипте.
- Оформляем workflow для сборки APK и AAB в YAML-файле.
name: Test_and_build_signed_artifacts_on_release
on:
pull_request:
branches:
- 'main'
env:
KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
RELEASE_SIGN_KEY_ALIAS: ${{ secrets.RELEASE_SIGN_KEY_ALIAS }}
RELEASE_SIGN_KEY_PASSWORD: ${{ secrets.RELEASE_SIGN_KEY_PASSWORD }}
jobs:
build_apk_aab:
if: startsWith(github.head_ref, 'release/') == true
name: Build release artifacts
runs-on: ubuntu-20.04
steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v1
with: {java-version: 1.8}
- name: Checkout keystore repo
uses: actions/checkout@v2
with:
repository: ${{ secrets.KEYSTORE_GIT_REPOSITORY }}
token: ${{ secrets.KEYSTORE_ACCESS_TOKEN }}
path: app/keystore
- name: Run tests and build release artifacts
run: |
./gradlew test
./gradlew assembleRelease --stacktrace
./gradlew bundleRelease
- name: Upload signed APK
uses: actions/upload-artifact@v2
with:
name: app-release.apk
path: app/build/outputs/apk/release/app-release.apk
- name: Upload AAB Bundle
uses: actions/upload-artifact@v2
with:
name: app-release.aab
path: app/build/outputs/bundle/release/app-release.aab
За основу был взят workflow, который был описан ранее. Запускается так же на pull request в main, только из веток, начинающихся на release/*. Вы можете поменять так, как вам удобно, это просто для иллюстрации возможностей.Что тут добавилось? Во-первых, в начале workflow записываются переменные окружения, вот тут:
env:
KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }}
RELEASE_SIGN_KEY_ALIAS: ${{ secrets.RELEASE_SIGN_KEY_ALIAS }}
RELEASE_SIGN_KEY_PASSWORD: ${{ secrets.RELEASE_SIGN_KEY_PASSWORD }}
Далее последовательно делаем два checkout - сначала на коммит в созданном pull request (это было и раньше), потом делаем checkout приватного репозитория с хранилищем.
- name: Checkout keystore repo
uses: actions/checkout@v2
with:
repository: ${{ secrets.KEYSTORE_GIT_REPOSITORY }}
token: ${{ secrets.KEYSTORE_ACCESS_TOKEN }}
path: app/keystore
Тут уже есть особенности. Необходимо передать в checkout@v2 аргумент, в какой репозиторий стучаться (repository), токен для доступа к нему (token) и path. Path - это путь внутри директории с основным проектом, куда нужно сложить файлы. Мы хотим получить хранилище в app/keystore. В принципе, не обязательно именно такой путь, главное указать выбранный путь в Gradle, чтобы он понимал, где искать хранилище. Полную документацию по checkout@v2 можно почитать тут. Дальше всё уже знакомое. Запускаем тесты и сборку релизной версии артефактов. На этом с workflow всё, дальше начинаем подготавливать build.gradle проекта.Редактируем build.gradle
signingConfigs {
release {
def keystoreProperties = new Properties()
def keystorePropsFile = file("keystore/keystore_config")
if (keystorePropsFile.exists()) {
file("keystore/keystore_config").withInputStream { keystoreProperties.load(it) }
storeFile file("$keystoreProperties.storeFile")
storePassword "$keystoreProperties.storePassword"
keyAlias "$keystoreProperties.keyAlias"
keyPassword "$keystoreProperties.keyPassword"
} else {
storeFile file("keystore/my_app_keystore")
storePassword System.getenv('KEYSTORE_PASSWORD')
keyAlias System.getenv('RELEASE_SIGN_KEY_ALIAS')
keyPassword System.getenv('RELEASE_SIGN_KEY_PASSWORD')
}
}
}
buildTypes {
release {
signingConfig signingConfigs.release
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
}
}
Идея заключается в том, что в заранее указанную директорию (app/keystore/) на CI автоматически добавится хранилище, а у себя локально мы можем без опаски хранить его в структуре проекта и даже положить туда файл с паролем в открытом виде. Это если нам хочется собирать и подписывать APK локально. Главное при этом добавить в gitignore всё содержимое app/keystore, чтобы случайно секретная информация не утекла с очередным коммитом.
*.iml
.gradle
/local.properties
/.idea/caches
/.idea/libraries
/.idea/modules.xml
/.idea/workspace.xml
/.idea/navEditor.xml
/.idea/assetWizardSettings.xml
.DS_Store
/build
/captures
.externalNativeBuild
.cxx
local.properties
/keystore # <-- вот эту строчку мы добавили
Чтобы Gradle понимал, где ему брать my_app_keystore в случае запуска assembleRelease локально и на CI, делаем нехитрую проверку. Сначала ищем keystore_config в директории keystore. Не нашли - делаем вывод, что нас запустили на CI и пароль следует брать не из keystore_config-файла, а из переменных окружения.keystore_config - тут стандартный способ хранить в открытом виде пароли, внутри он состоит из пар key=value. Всё то же самое, что мы записывали в секреты на GitHub, но в открытом виде.
storeFile=keystore/my_app_keystore
storePassword=654321
keyAlias=sign_apk_key
keyPassword=123456
Само зашифрованное хранилище кладём рядом, в той же директории.Если потребности подписывать APK локально нет или хочется вручную запускать процесс через “Generate Signed Bundle / APK”, выбирая каждый раз нужный keystore, то можно всё упростить и оставить только часть про System.getenv() Тут самостоятельно примите решение, что вам подходит, безопасное хранение паролей - действительно важная история.Пробуем запустить на CI
Отлично! То, что нам нужно, - готовый к релизу артефакт, собранный автоматически на GitHub Actions.Запускаем локально.В Android Studio переходим в терминал, запускаем.
./gradlew assembleRelease
После успешного завершения подписанный APK будет ждать нас в app/build/outputs/apk/release.
На этом со сборкой артефактов можно закончить, самые базовые кейсы рассмотрены. Чтобы потренироваться с этим, предлагаю вам самостоятельно настроить подпись для debug-сборок. И еще одно самостоятельное задание для заинтересовавшихся: чтобы сделать проект еще красивее, по проставлению в git tag версии приложения (например, v1.0.0) собирать APK, подписывать и складывать в разделе релизов прямо в GitHub репозитории с правильным названием, включающим версию из tag.Подсказка - удобно использовать https://github.com/actions/create-release, там в описании есть похожий на нашу задачу workflow.Выводим на README.MD статус выполнения workflowЗдорово смотрятся бейджи со статусом прохождения этапов CI на главной странице репозитория. Наверняка вы много раз видели похожие бейджики с процентом покрытия тестами кода, статусом сборки и так далее. Давайте прямо сейчас сделаем такие для статуса прохождения unit-тестов, для этого у нас уже всё есть.Итак, у нас уже есть несколько workflow. Документация очень подробная и с примерами.Открываем README.md и пишем что-то вроде этого, подставляя своё реальное имя на GitHub, название текущего репозитория и имя workflow, для которого хочется иметь бейджик.
Feature branch Unit tests status
![PR_unit_tests](https://github.com/{your_github_acc_name}/{repository_name}/workflows/PR_unit_tests/badge.svg)
Main branch status
![main](https://github.com/{your_github_acc_name}/{repository_name}/workflows/Hello_world/badge.svg)
Сохраняем и смотрим результат.
По-моему, круто всего для двух минут настройки. Теперь всегда будет видно текущий статус прогона тестов. А ещё можно будет добавить статус сборки APK для релизных веток, что-нибудь от статического анализатора кода вроде Sonarcube, в общем, всё, что пожелаете.На этом первая часть рассказа про GitHub Actions заканчивается. За короткое время мы смогли настроить очень неплохую автоматизацию для проекта. В следующей части продолжим тему тестирования и посмотрим как настроить запуск UI тестов в Firebase Test Lab. Не пропустите, будет интересно.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, GitHub, Статистика в IT] GitHub опубликовал ежегодный статистический отчет
- GitHub опубликовал статистику за 2020 год
- [Разработка веб-сайтов, Системное администрирование, DevOps, Микросервисы] End User Monitoring на примере Instana
- [IT-инфраструктура, Amazon Web Services, DevOps, Облачные сервисы] AWS re:Invent. Главные анонсы первого дня (Part 2)
- [IT-инфраструктура, Amazon Web Services, DevOps, Облачные сервисы] AWS re:Invent. Главные анонсы первого дня (Part 1)
- [Системное администрирование, IT-инфраструктура, Amazon Web Services, DevOps] Terraform 12 и Terragrunt и как это можно применять для Multi-Cloud-инфраструктуры. Александр Довнар
- Приложение, дающее прямые ссылки на артифакты от GitHub Actions
- [Python, Тестирование веб-сервисов] Настройка GitHub Actions для автоматизированного тестирования средствами Python в конвейере CI/CD (перевод)
- [Программирование, Разработка под Android] Рисование собственных представлений (View) в Android (перевод)
- [Программирование, Разработка под Android, Kotlin] Меняем стандартный диалог сбоя приложения в Android на собственный экран (перевод)
Теги для поиска: #_razrabotka_pod_android (Разработка под Android), #_devops, #_github, #_ci/cd, #_tutorial, #_android, #_android_development, #_testing, #_unittesting, #_github_actions, #_blog_kompanii_tutu.ru (
Блог компании Туту.ру
), #_razrabotka_pod_android (
Разработка под Android
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:01
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Привет!Это пост для тех, кто заинтересовался возможностями GitHub Actions, но никогда не имел опыта реальной настройки build-систем. Примеры будут полезны как для прокачки собственного pet-проекта, так и для понимания, как настраивается CI/CD, если по работе нет связанных с этим задач.Что будет рассмотрено:
RunnerЭто развёрнутый в облаке от GitHub или self-hosted сервер с настроенным окружением и который может запускать workflow внутри себя.WorkflowЭто независимый процесс, автоматически запускаемый на GitHub Actions в отдельном контейнере по получению Event. Каждый workflow описывается отдельным YAML-файлом.Состоит из более мелких структурных единиц исполнения - Jobs.JobСоставная часть workflow, в свою очередь состоит из отдельных шагов Steps. Jobs могут быть настроены на параллельное и последовательное выполнение.StepЕще более мелкая единица исполнения скрипта, состоит из набора команд или действий.ActionsСамая маленькая структурная единица исполнения скрипта workflow. Action может делать в принципе всё что угодно, например, проставлять теги с версией приложения в Git или отправлять собранный AAB в Google Play.Можно писать как собственный Action, так и пользоваться готовыми. Action по сути выступает наравне с другими командами внутри Step.Самые распространённые Action - это checkout на коммит и установка Java-окружения. По умолчанию, если специально не встать на нужный коммит, Job ничего не знает о проекте, из которого он запущен.Пример ниже подготавливает окружение, а Uses указывает скрипту, что необходимо дождаться их окончания, прежде чем выполняться дальше. - uses: actions/checkout@v1
- uses: actions/setup-java@v1 При создании нового workflow GitHub пытается проанализировать содержимое репозитория и предлагает шаблон на выбор. На самые популярные сценарии сборки и деплоя можно найти заготовки.Все workflow конфигурируются через файлы в формате YAML, это фактически стандарт для CI/CD-систем.Чтобы GitHub Actions начала выполнять таски, необходимо положить их в определённым образом названную директорию в корне проекта github/workflows.Добавлять и редактировать конфиги можно как в Android Studio, так и в самом GitHub на вкладке Actions. Так и поступим. Сами конфиги в YAML можно называть как угодно, но лучше давать осмысленные имена для того, чтобы позднее самому понимать, что именно тут настроено.GitHub сразу же подставляет самый простой скрипт, который делает checkout на новый коммит, выводит в консоль несколько строк и заканчивает работу. Что-то ещё проще придумать сложно, но даже в этом примере есть что посмотреть. # This is a basic workflow to help you get started with Actions
name: CI # Controls when the action will run. Triggers the workflow on push or pull request # events but only for the develop branch on: push: branches: [ main ] pull_request: branches: [ main ] # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" build: # The type of runner that the job will run on runs-on: ubuntu-latest # Steps represent a sequence of tasks that will be executed as part of the job steps: # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - uses: actions/checkout@v2 # Runs a single command using the runners shell - name: Run a one-line script run: echo Hello, world! # Runs a set of commands using the runners shell - name: Run a multi-line script run: | echo Add other actions to build, echo test, and deploy your project. Но когда этот workflow будет отрабатывать? Ведь мы раньше упоминали, что в GitHub Actions все workflow запускаются не сами по себе, а только при получении того event’а, который прописан в самом yml-скрипте. on:
push: branches: [ main ] pull_request: branches: [ main ] Уже неплохо! Обычно после первого знакомства с новой технологией сразу хочется усложнить свой hello world и заставить его делать хоть что-то полезное, кроме вывода текста в консоль.Запуск unit-тестов на каждый pull request в mainПервый YAML-скрипт мы создавали в веб-интерфейсе GitHub, теперь сделаем то же самое в Android Studio.Чтобы увидеть директорию с YAML-файлами, нужно переключить режим просмотра на “Project” (если вдруг у вас был выбран режим “Android”).Находим директорию workflows и создаём новый файл с типом YML. Назовём его, к примеру, run_unit_tests.yml.Пока что всё, что мы хотим от скрипта, - это запускать unit-тесты на каждом pull request в ветку main. Можно скопировать целиком код из примера, всё должно работать. Если GitHub покажет, что в YAML ошибка, то проверить в первую очередь стоит правильность форматирования и количество отступов у блоков, так как формат чувствителен к этому. name: PR_unit_tests
on: pull_request: branches: - 'main' jobs: Unit-test: name: Run unit tests on PR in main runs-on: ubuntu-20.04 steps: - uses: actions/checkout@v2 - uses: actions/setup-java@v1 with: {java-version: 1.8} - name: Run unit tests run: ./gradlew test Я специально испортил один unit-тест, чтобы показать ещё одну базовую настройку вашего CI/CD-пайплайна - запрет на merge в ветку main c поломанными тестами. Всё логично: если ваш новый коммит что-то поломает в бизнес-логике приложения, то автоматика не даст сделать по ошибке merge. Или по крайней мере предупредит о проблеме.Настраивается это очень просто: заходим в Settings репозитория, вводим в “Branch name pattern” паттерн для тех веток, для которых хотим создать новое правило безопасности. В нашем случае можно ввести “main”. Далее проставляем галочки в нужных условиях правила и сохраняем. Всё готово, вы только что создали своё первое правило для merge в своем репозитории. Смотрим теперь, как поведёт себя автоматика с pull-request, в котором поломаны тесты. Работает! При желании можно запретить merge с проблемами даже для администраторов, там же в настройках merge protection rule.Если хочется прямо сейчас самостоятельно что-то настроить, то вот несложное задание. Gradle task test, который мы запускали, генерит небольшой отчет по результатам запуска unit-тестов, всё лежит в app/build/reports/tests/testDebugUnitTest/ Попробуйте самостоятельно добавить после шага Run unit tests ещё один шаг, который выкачивает отчет по тестированию.Подсказка - использовать actions/upload-artifact@v2На этом часть про запуск unit-тестов закончена, дальше настроим сборку и подпись релизного APK.Задачу сформулируем так: подготавливать нам APK и AAB и подписывать ключом из keystore. Причём сборку мы будем запускать только на pull request в main из веток с именем, начинающимся с release/Задача стала чуть сложнее, поэтому будем рассматривать ее по шагам.Шаг 1. Собираем APK и AAB. Пока не подписываем name: Test_and_build_artifacts_on_release
on: pull_request: branches: - 'main' jobs: build_apk_aab: if: startsWith(github.head_ref, 'release/') == true name: Build release artifacts runs-on: ubuntu-20.04 steps: - uses: actions/checkout@v2 - uses: actions/setup-java@v1 with: {java-version: 1.8} - name: Build release APK and AAB after test run: | ./gradlew test ./gradlew assembleRelease ./gradlew bundleRelease - name: Upload APK uses: actions/upload-artifact@v2 with: name: app-release.apk path: app/build/outputs/apk/release/app-release-unsigned.apk - name: Upload AAB Bundle uses: actions/upload-artifact@v2 with: name: app-release.aab path: app/build/outputs/bundle/release/app-release.aab if: startsWith(github.head_ref, 'release/') == true
run: |
./gradlew test ./gradlew assembleRelease --stacktrace ./gradlew bundleRelease - name: Upload APK
uses: actions/upload-artifact@v2 with: name: app-release.apk path: app/build/outputs/apk/release/app-release-unsigned.apk Шаг 2. Подписываем APKСначала немного теории, как и зачем вообще подписывать APK.Цифровая подпись необходима для того, чтобы Google Play мог идентифицировать разработчика и в дальнейшем только он мог обновлять приложение, это крайне важная вещь в процессе размещения проекта в магазине приложений. В целях безопасности цифровая подпись хранится не в открытом виде, а в специальном хранилище типа key value - файле с расширением jks или keystore. Сам файл хранилища стоит держать в надёжном месте, это, можно сказать, паспорт вашего приложения.Как создать keystoreЕсли вы уже выложили своё приложение в Google Play, то ключ у вас точно есть. Если же нет - ниже простая инструкция.Вариантов два - создать через консоль или через IDE.
$ keytool -genkey -v -keystore my_app_keystore.keystore -alias app_sign_key -keyalg RSA -keysize 2048 -validity 10000
Чтобы собранный APK успешно подписать ключом из хранилища, необходимо этот самый ключ достать по имени (key alias), предварительно получив доступ через пароль к хранилищу (store password) и пароль непосредственно к ключу (key password). Это происходит в рамках специального Gradle task, всё будет далее автоматизировано.Дополнительная информацияhttps://developer.android.com/studio/build/building-cmdline#gradle_signinghttps://developer.android.com/studio/publish/app-signing#secure-shared-keystorehttps://developer.android.com/studio/publish/app-signing#sign-autoИ тут возникает два вопроса.
После добавления секретов к ним можно обращаться через специальный синтаксис прямо из YAML-скриптов. Например, вот так мы запишем EXAMPLE_API_KEY_1 в переменную окружения и затем в Gradle-скрипте, которому она понадобится, достанем её через System.getenv('EXAMPLE_API_KEY_1') env:
API_KEY: ${{ secrets.EXAMPLE_API_KEY }} Звучит не очень сложно, смотрим, как такое настроить в GitHub Actions.
name: Test_and_build_signed_artifacts_on_release
on: pull_request: branches: - 'main' env: KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }} RELEASE_SIGN_KEY_ALIAS: ${{ secrets.RELEASE_SIGN_KEY_ALIAS }} RELEASE_SIGN_KEY_PASSWORD: ${{ secrets.RELEASE_SIGN_KEY_PASSWORD }} jobs: build_apk_aab: if: startsWith(github.head_ref, 'release/') == true name: Build release artifacts runs-on: ubuntu-20.04 steps: - uses: actions/checkout@v2 - uses: actions/setup-java@v1 with: {java-version: 1.8} - name: Checkout keystore repo uses: actions/checkout@v2 with: repository: ${{ secrets.KEYSTORE_GIT_REPOSITORY }} token: ${{ secrets.KEYSTORE_ACCESS_TOKEN }} path: app/keystore - name: Run tests and build release artifacts run: | ./gradlew test ./gradlew assembleRelease --stacktrace ./gradlew bundleRelease - name: Upload signed APK uses: actions/upload-artifact@v2 with: name: app-release.apk path: app/build/outputs/apk/release/app-release.apk - name: Upload AAB Bundle uses: actions/upload-artifact@v2 with: name: app-release.aab path: app/build/outputs/bundle/release/app-release.aab env:
KEYSTORE_PASSWORD: ${{ secrets.KEYSTORE_PASSWORD }} RELEASE_SIGN_KEY_ALIAS: ${{ secrets.RELEASE_SIGN_KEY_ALIAS }} RELEASE_SIGN_KEY_PASSWORD: ${{ secrets.RELEASE_SIGN_KEY_PASSWORD }} - name: Checkout keystore repo
uses: actions/checkout@v2 with: repository: ${{ secrets.KEYSTORE_GIT_REPOSITORY }} token: ${{ secrets.KEYSTORE_ACCESS_TOKEN }} path: app/keystore signingConfigs {
release { def keystoreProperties = new Properties() def keystorePropsFile = file("keystore/keystore_config") if (keystorePropsFile.exists()) { file("keystore/keystore_config").withInputStream { keystoreProperties.load(it) } storeFile file("$keystoreProperties.storeFile") storePassword "$keystoreProperties.storePassword" keyAlias "$keystoreProperties.keyAlias" keyPassword "$keystoreProperties.keyPassword" } else { storeFile file("keystore/my_app_keystore") storePassword System.getenv('KEYSTORE_PASSWORD') keyAlias System.getenv('RELEASE_SIGN_KEY_ALIAS') keyPassword System.getenv('RELEASE_SIGN_KEY_PASSWORD') } } } buildTypes { release { signingConfig signingConfigs.release minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } *.iml
.gradle /local.properties /.idea/caches /.idea/libraries /.idea/modules.xml /.idea/workspace.xml /.idea/navEditor.xml /.idea/assetWizardSettings.xml .DS_Store /build /captures .externalNativeBuild .cxx local.properties /keystore # <-- вот эту строчку мы добавили storeFile=keystore/my_app_keystore
storePassword=654321 keyAlias=sign_apk_key keyPassword=123456 Отлично! То, что нам нужно, - готовый к релизу артефакт, собранный автоматически на GitHub Actions.Запускаем локально.В Android Studio переходим в терминал, запускаем. ./gradlew assembleRelease
На этом со сборкой артефактов можно закончить, самые базовые кейсы рассмотрены. Чтобы потренироваться с этим, предлагаю вам самостоятельно настроить подпись для debug-сборок. И еще одно самостоятельное задание для заинтересовавшихся: чтобы сделать проект еще красивее, по проставлению в git tag версии приложения (например, v1.0.0) собирать APK, подписывать и складывать в разделе релизов прямо в GitHub репозитории с правильным названием, включающим версию из tag.Подсказка - удобно использовать https://github.com/actions/create-release, там в описании есть похожий на нашу задачу workflow.Выводим на README.MD статус выполнения workflowЗдорово смотрятся бейджи со статусом прохождения этапов CI на главной странице репозитория. Наверняка вы много раз видели похожие бейджики с процентом покрытия тестами кода, статусом сборки и так далее. Давайте прямо сейчас сделаем такие для статуса прохождения unit-тестов, для этого у нас уже всё есть.Итак, у нас уже есть несколько workflow. Документация очень подробная и с примерами.Открываем README.md и пишем что-то вроде этого, подставляя своё реальное имя на GitHub, название текущего репозитория и имя workflow, для которого хочется иметь бейджик. Feature branch Unit tests status
![PR_unit_tests](https://github.com/{your_github_acc_name}/{repository_name}/workflows/PR_unit_tests/badge.svg) Main branch status ![main](https://github.com/{your_github_acc_name}/{repository_name}/workflows/Hello_world/badge.svg) По-моему, круто всего для двух минут настройки. Теперь всегда будет видно текущий статус прогона тестов. А ещё можно будет добавить статус сборки APK для релизных веток, что-нибудь от статического анализатора кода вроде Sonarcube, в общем, всё, что пожелаете.На этом первая часть рассказа про GitHub Actions заканчивается. За короткое время мы смогли настроить очень неплохую автоматизацию для проекта. В следующей части продолжим тему тестирования и посмотрим как настроить запуск UI тестов в Firebase Test Lab. Не пропустите, будет интересно. =========== Источник: habr.com =========== Похожие новости:
Блог компании Туту.ру ), #_razrabotka_pod_android ( Разработка под Android ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:01
Часовой пояс: UTC + 5