Автоматизируйте рабочий процесс разработчика прямо из GitHub

Действия GitHub стали доступны каждому пользователю GitHub в 2020 году, поэтому они все еще относительно новые. Знаете ли вы, что каждый месяц у вас есть 2000 бесплатных минут для ваших личных репозиториев? Более того, общедоступные репозитории получают неограниченное количество минут бесплатно.

Вам даже не нужно создавать большую часть экшена самостоятельно, на GitHub есть рынок, полный бесплатных экшенов, которые вы можете использовать. Итак, на какие простые действия вы могли бы потратить все эти свободные минуты?

Анализ кода

Linting позволяет автоматически проверять код на программные и стилистические проблемы. Код намного легче читать, если он написан последовательным образом, поэтому линтеры стремятся обеспечить единый стиль для вашего кода.

Запуск линтинга кода до того, как PR будет объединен с основной веткой, — отличный вариант использования GitHub Action, и это очень просто сделать! Вот как я это сделал для репозитория Ruby:

name: Ruby

on:
  pull_request:
  workflow_dispatch:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Set up Ruby
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: '2.7.1'
        bundler-cache: true
    - name: Run Rubocop Linting
      run: bundle exec rubocop

Действия GitHub определяются с помощью YAML. Поскольку это первое действие GitHub, которое мы рассматриваем, я пройду его шаг за шагом:

name: Ruby

Начнем с простого, это имя для этого конкретного действия GitHub.

on:
  pull_request:
  workflow_dispatch:

Далее мы определяем, какие события должны запускать действие GitHub. В этом случае мы выбираем выполнение этого действия всякий раз, когда запрос на вытягивание открывается, повторно открывается или фиксируется. Это значения по умолчанию, но вы можете запускать события по многочисленным событиям, связанным с запросами на включение, которые вы можете увидеть здесь.

Второе событие, которое мы указываем, — это диспетчеризация рабочего процесса, что позволяет нам запускать действие вручную на вкладке «Действия» для репозитория. Я нахожу это особенно полезным при тестировании действия.

jobs:
  lint:
    runs-on: ubuntu-latest

Теперь, когда мы определили, когда действие должно выполняться, мы можем указать, что оно должно делать. Действия разбиты на задания (вы можете определить несколько для каждого действия). В этом случае у нас есть одно задание с именем lint, и мы должны определить, в какой среде запускать действие GitHub.

Я выбрал Linux, но также доступны Windows и macOS. Все эти бегуны размещаются на GitHub, что делает их очень доступными для всех, но если вам нужны более мощные бегуны или требуется специальное оборудование или инструменты, вы можете самостоятельно разместить бегунов.

- uses: actions/checkout@v2
- name: Set up Ruby
  uses: ruby/setup-ruby@v1
    with:
      ruby-version: '2.7.1'
      bundler-cache: true
- name: Run Rubocop Linting
  run: bundle exec rubocop

Каждое задание может иметь несколько шагов, определенных в виде списка. Большинство действий всегда начинаются с действия проверки, созданного GitHub, и оно извлекает ваш репозиторий в средство выполнения.

Затем мы углубимся в специфику этого действия. Во-первых, мы должны установить Ruby, для чего снова доступно предварительно настроенное действие. Мы можем передавать параметры действиям, например версию Ruby для этого действия. Параметр bundler-cache установит зависимости (gems ​​в Ruby).

Наконец, мы можем проверить наш код. Rubocop — это линтер для Ruby, и после запуска он либо выдаст код выхода 0 (успех), и действие будет выполнено, либо код выхода 1 (сбой), и действие завершится ошибкой. Если есть сбои, они доступны для просмотра в выходных данных бегуна. Вы можете увидеть пример бегуна здесь.

Использование действий GitHub для проверки статуса

Если бы мы просто запускали это действие в фоновом режиме, оно было бы бесполезным. Вероятность того, что инженеры заглянут во вкладку «Действия» перед объединением своего PR, довольно мала.

Однако GitHub позволяет вам определять проверки статуса для запросов на вытягивание. Эти проверки состояния можно настроить так, чтобы слияние разрешалось только после того, как все проверки состояния пройдены.

Таким образом, вместо того, чтобы инженерам приходилось помнить о проверке действия, мы можем гарантировать, что линтинг пройдет до слияния PR. Вот пример PR, который в настоящее время заблокирован из-за неудачного анализа.

Тестирование вашего приложения

В наши дни большинство приложений и библиотек имеют ту или иную форму автоматического тестирования. Существует множество инструментов для запуска ваших тестов, но почему бы не использовать GitHub Actions?

Вот как я запускаю свои тесты для одного из m репозиториев C#:

name: .NET

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 3.1.x
    - name: Restore
      run: dotnet restore
    - name: Build
      run: dotnet build --no-restore
    - name: Test
      run: dotnet test --no-build --verbosity normal

Я не буду описывать каждый шаг, как в прошлый раз, так как теперь мы знаем основную структуру действий. Однако есть несколько отличий:

on:
  push:
    branches: [ main ]

Во-первых, мы запускаем тесты при каждом нажатии — поэтому, даже если запрос на включение не инициируется, мы все равно запускаем тесты. Это очень ценно, так как часто инженеры хотят увидеть результаты тестов, прежде чем поднимать PR.

Хотя я бы рекомендовал запускать его при каждом нажатии на каждую ветку, просто чтобы продемонстрировать гибкость действий GitHub, я указал, что действие должно выполняться только для основной ветки. Вы также можете указать пути, в результате чего действие будет выполняться только при изменении определенных файлов.

- name: Setup .NET
  uses: actions/setup-dotnet@v1
    with:
     dotnet-version: 3.1.x
- name: Restore
  run: dotnet restore
- name: Build
  run: dotnet build --no-restore
- name: Test
  run: dotnet test --no-build --verbosity normal

Первый шаг — установить .NET, для чего сам GitHub предоставляет действие. Это действие делает .NET CLI доступным для исполнителя, где мы можем создавать и запускать наши тесты.

Как и в приведенном выше линтинге, соответствующий код выхода будет возвращен в зависимости от того, пройдены или не пройдены тесты. Вот пример его запуска и прохождения. Как и в случае с линтингом, мы можем использовать проверки состояния, чтобы гарантировать, что только ветки с зелеными тестами могут быть объединены.

Сканируйте ваше приложение на наличие уязвимостей

Наконец, последний простой вариант использования, который я собираюсь рассмотреть, — это сканирование вашего репозитория на наличие уязвимостей. Для этого мы воспользуемся мощью торговой площадки GitHub, так как одним из главных преимуществ использования действий является растущее количество бесплатных действий, доступных для мгновенного использования.

Я собираюсь использовать действие Snyk’s GitHub, так как я обнаружил, что его легко настроить и он обеспечивает поддержку многих языков, включая Node, .NET, Scala и Docker.

Вы можете зарегистрировать бесплатную учетную запись Snyk здесь, чтобы начать работу (оплачиваемые тарифные планы доступны для крупных организаций). Вам понадобится учетная запись, чтобы получить доступ к вашему токену API. Если у вас есть токен API, настроить действие очень просто:

name: Synk Security Checks
on:
  push:
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

В качестве примера я использовал Node, но вы можете изменить действие на любой из поддерживаемых языков. Это действие вводит одну новую концепцию — переменные среды.

Для выполнения этого действия необходимо установить переменную среды SNYK_TOKEN. Мы не хотим хранить секреты в открытом виде в репозитории, но вы можете настроить секреты, перейдя в репозиторий, щелкнув настройки, а затем в левом меню секреты, за которыми следуют действия.

На этой странице вы можете определить пары ключ-значение, состоящие из секретного имени и соответствующего ему значения. После сохранения вы можете получить доступ ко всем секретам репозитория, в котором выполняется действие, используя ${{ secrets.YOUR_SECRET_NAME }} .

Последние мысли

Надеюсь, теперь у вас есть базовое представление о GitHub Actions. Это только начало, и по мере распространения я ожидаю, что количество доступных действий значительно возрастет.

Действия, которые мы видели в этой статье, очень просты, но эффективны, но я знаю компании, которые запускают все свои конвейеры развертывания на действиях GitHub, поэтому более сложные варианты использования также подходят им. Если вы проданы, я бы порекомендовал проверить полную документацию на GitHub.

Want to Connect?
I run a free newsletter providing fortnightly technical book recommendations, including my key takeaways from the books. Interested? Sign up here!