непрерывной интеграции, ci было похоже на хороший выбор.
Затем вы можете добавить в файл ci.yml следующее содержимое:
name: CI
on:
pull_request:
branches:
- 'master'
schedule:
- cron: '37 0 * * *' # Nightly at 00:37
jobs:
Каждый файл рабочего процесса должен определять свое имя и причину его запуска. В этом примере я назвал рабочий процесс CI и настроил его на запуск каждый раз, когда в главную ветку поступает запрос на включение. Он также будет работать ежедневно в 37 минут после полуночи. В GitHub Actions рабочий процесс (workflow) представляет собой набор связанных заданий, где задание (job) — это набор шагов, которые будут выполняться для достижения определенной цели. Как видите, мы удалили карту вакансий, в которой будут определены все наши вакансии.
В демонстрационных целях мы собираемся провести наши тесты как для последних, так и для ночных выпусков Crystal, а также запустить их как на Linux, так и на macOS. Как упоминалось ранее, не стесняйтесь настраивать платформы по своему усмотрению. GitHub Actions поддерживает концепцию, называемую матрицами, которая позволяет нам определить одно задание, которое будет создавать дополнительные задания для каждой комбинации. Мы доберемся до этого в ближайшее время. Во-первых, давайте сосредоточимся на двух более простых задачах — стандартах форматирования и кодирования.
Обновите карту вакансий нашего файла ci.yml, чтобы она выглядела следующим образом:
jobs:
check_format:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install Crystal
uses: crystal-lang/install-crystal@v1
- name: Check Format
run: crystal tool format --check
coding_standards:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install Crystal
uses: crystal-lang/install-crystal@v1
- name: Install Dependencies
run: shards install
- name: Ameba
run: ./bin/ameba
На высоком уровне эти профессии очень похожи. Мы настроили их для работы в последней версии Ubuntu, используя последний Crystal Alpine Docker image. Конечно, шаги для каждого из них немного отличаются, но оба они начинаются с проверки кода вашего проекта.
Для проверки форматирования можно просто запустить run crystal tool format --check. Если он отформатирован неправильно, он вернет ненулевой код выхода, как мы узнали недавно, что приведет к сбою задания. Задание по стандартам кодирования начинается так же, но также будет выполняться run shards install для установки Ameba. Наконец, он запускает Ameba, которая также вернет ненулевой код выхода в случае сбоя. Далее давайте перейдем к заданию, которое будет запускать наши тесты.
Добавьте следующий код в карту заданий:
test:
strategy:
fail-fast: false
matrix:
os:
- ubuntu-latest
- macos-latest
crystal:
- latest
- nightly
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v2
- name: Install Crystal
uses: crystal-lang/install-crystal@v1
with:
crystal: ${{ matrix.crystal }}
- name: Install Dependencies
run: shards install
- name: Specs
run: crystal spec --order=random --error-on- warnings
Эта работа немного сложнее двух последних. Давайте сломаем это!
В этом задании представлено отображение стратегию (strategy), которое включает данные, описывающие, как должно выполняться задание. Две основные функции, которые мы используем, включают отказоустойчивость (fail-fast) и матрицу (matrix). Первый вариант делает так, что если одно из заданий, созданных с помощью матрицы, потерпит неудачу, оно не потерпит крах все из них. Мы хотим, чтобы это значение было false, чтобы, например, ночной сбой Crystal на определенной платформе не приводил к сбою всех остальных заданий.
Как упоминалось ранее, отображение матрицы, как следует из названия, позволяет определить матрицу, которая будет создавать задание для каждой комбинации значений матрицы. В итоге наша матрица определит четыре вакансии:
• Последняя версия Crystal для Ubuntu
• Crystal Nightly в Ubuntu
• Последняя версия Crystal для macOS.
• Crystal Nightly на macOS.
Дополнительные части конфигурации задания шаблонизированы для использования значений из матрицы, например для указания того, на чем выполняется задание и какую версию Crystal установить. Мы также используем https://github.com/crystal-lang/install-crystal для установки Crystal, который работает кросс-платформенно.
Затем мы запускаем shards install, чтобы установить любые зависимости. Если ваш проект не имеет каких-либо зависимостей, смело удаляйте этот шаг. Наконец, мы запускаем спецификации в случайном порядке, а также выдаем ошибку при обнаружении каких-либо предупреждений от любых зависимостей, включая сам Crystal. Основная причина этого — выявить будущие недостатки ночной работы Crystal, чтобы их можно было устранить.
Отсюда вы можете рассмотреть возможность добавления некоторых правил защиты ветвей, например, http://docs.github.com/en/rePositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging, чтобы потребовать прохождения определенных проверок перед объединением запроса на включение.
Теперь, когда мы применяем стандарты форматирования, кодирования и тесты, мы можем перейти к развертыванию нашей документации.
Развертывание документации
Существует множество различных способов, которыми мы могли бы использовать наши развертывания документации, как с точки зрения того, какие функции мы хотим поддерживать, где они будут размещены, так и с точки зрения того, как должна быть создана документация. Например, вы можете захотеть поддерживать отображение документации для каждой версии вашего приложения, или вы можете захотеть самостоятельно разместить ее, или вам может потребоваться включить документацию из других сегментов.
В примере, который мы собираемся рассмотреть, я размещу документацию на веб-сайте https://pages.github.com, только с последней версией, без каких-либо внешних зависимостей. Таким образом, вам нужно будет обязательно настроить GitHub Pages для вашего репозитория.
Совет
см. https://docs.github.com/en/pages/quickstart для получения дополнительной информации о том, как это настроить.
Теперь, когда с этим покончено, мы можем перейти к настройке рабочего процесса! Поскольку развертывание документации — это то, что должно произойти только после публикации новой версии, мы собираемся создать для этого специальный рабочий процесс. Начните с создания файла deployment.yml в папке workflows. В этот файл можно добавить следующее содержимое:
name: Deployment
on:
release:
types:
- created
jobs:
deploy_docs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install Crystal
uses: crystal-lang/install-crystal@v1
- name: Build
run: crystal docs
- name: Deploy
uses: JamesIves/github-pages-deploy-action@4.1.5
with:
branch: gh-pages
folder: docs
single-commit: true
Начав так же, как и раньше, мы даем имя этому
