Прокачиваем Android проект с GitHub Actions. Часть 103.12.2020 10:18

Привет!

Это пост для тех, кто заинтересовался возможностями 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

И тут возникает два вопроса.

1. Где хранить пароли от хранилища, не в открытом же виде прописывать их в конфигах?

2. Как и куда выкладывать само хранилище ключей для открытого проекта?  

Для хранения секретных данных, например, таких как идентификаторы приложения в 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.

1. Создаем приватный репозиторий и помещаем туда только хранилище ключей.

   

2.  Генерируем Personal access token для доступа к приватному репозиторию с хранилищем. 

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

3. Добавляем Personal access token из предыдущего шага в секреты основного проекта под любым именем, например KEYSTORE_ACCESS_TOKEN.

4. Добавляем все пароли и key_alias от хранилища. 

   Добавляем название аккаунта и имя приватного репозитория туда же в секреты основного проекта через слеш, что-то вроде «another-account/secret-repo». Это понадобится нам дальше, когда будем клонировать репозиторий с ключом в YAML-скрипте.

   

5. Оформляем 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. Не пропустите, будет интересно.

© Habrahabr.ru