Crystal Programming. Введение на основе проекта в создание эффективных, безопасных и читаемых веб-приложений и приложений CLI - Джордж Дитрих

Затем вы можете добавить в файл 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/[email protected]

      with:

        branch: gh-pages

        folder: docs

        single-commit: true

Начав так же, как и раньше, мы даем имя этому