Как GitHub Actions автоматизирует задачи разработки?

Завершено

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

GitHub ускоряет процесс разработки

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

• Коммуникация — GitHub предоставляет разработчикам множество простых возможностей, облегчая общение в рамках проекта по разработке ПО: проверка кода в pull-запросах, обсуждение задач на GitHub, доски проектов, вики-страницы, уведомления и многое другое.
• Автоматизация — действия GitHub Actions позволяют вашей команде автоматизировать рабочие процессы на каждом этапе разработки ПО (от интеграции до развертывания). Вы даже можете автоматизировать добавление меток к запросам на вытягивание и проверку устаревших запросов и нерешенных проблем.

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

Использование автоматизации рабочих процессов для ускоренной разработки

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

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

• Убедитесь, что код проходит все модульные тесты.
• Выполните проверки качества и соответствия кода, чтобы убедиться, что исходный код соответствует стандартам организации.
• Проверьте код и его зависимости для известных проблем безопасности.
• Создайте код, интегрируя новый исходный код из (потенциально) нескольких участников.
• Убедитесь, что программное обеспечение проходит тесты интеграции.
• Укажите версию новой сборки.
• Доставите новые двоичные файлы в соответствующее расположение файловой системы.
• Разверните новые двоичные файлы на одном или нескольких серверах.
• Определите, не соответствуют ли требованиям какие-либо из этих задач, и сообщите о проблеме соответствующему лицу или команде для разрешения.

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

Что такое GitHub Actions?

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

Где можно найти GitHub Actions?

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

Но помимо тех GitHub Actions, которые представлены на вкладке Действий в GitHub, вы можете:

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

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

Многие действия GitHub имеют открытый код и доступны для всех, кто хочет их использовать. Тем не менее, перед использованием в проекте их необходимо тщательно проверить, как и любое программное обеспечение с открытым кодом. Как и рекомендуемые стандарты сообщества с программным обеспечением с открытым исходным кодом, например README, код поведения, участие в файлах и шаблонах проблем, вы можете следовать этим рекомендациям при использовании GitHub Actions:

• Проверьте входные и выходные данные файла действия action.yml, чтобы убедиться в правильности кода.
• Проверьте, находится ли действие в GitHub Marketplace. Эта проверка стоит, даже если действие не должно находиться в GitHub Marketplace, чтобы быть допустимым.
• Убедитесь, проверено ли действие в GitHub Marketplace. Проверка означает, что GitHub одобрил использование этого действия. Тем не менее, его необходимо проверить перед использованием.
• Добавьте версию используемого действия, указав ссылку на Git, SHA или тег.

Типы действий GitHub

Существует три типа действий GitHub: действия контейнера, действия JavaScript и составные действия.

При использовании действий контейнера среда является частью кода действия. Эти действия могут выполняться только в среде Linux, в которой размещены узлы GitHub. Действия контейнера поддерживают множество различных языков.

Действия JavaScript не включают среду в код. Необходимо указать среду для выполнения этих действий. Эти действия можно выполнить на виртуальной машине (виртуальной машине) в облаке или локальной среде. Действия JavaScript поддерживают среды Linux, macOS и Windows.

Составные действия позволяют объединить несколько шагов рабочего процесса в одном действии. Например, с помощью этой функции можно объединить несколько команд выполнения в действие, а затем использовать рабочий процесс, который выполняет такие объединенные команды за один шаг с помощью этого действия.

Анатомия действия GitHub

Ниже приведен пример действия, которое выполняет извлечение репозитория из Git. Это действие, actions/checkout@v1, является частью шага в рабочем процессе. На этом шаге также выполняется сборка кода Node.js, который был извлечен. В следующем разделе мы будем говорить о рабочих процессах, заданиях и шагах.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

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

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

Обратите внимание на раздел inputs. Здесь вы получаете значение переменной с именем MY_NAME. Эта переменная устанавливается в рабочем процессе, который запускает это действие.

В разделе runs обратите внимание, что вы указываете docker в атрибуте uses. При установке этого значения необходимо указать путь к файлу образа Docker. В этом случае Dockerfile. Мы не охватываем особенности Docker здесь, но если вы хотите получить дополнительные сведения, ознакомьтесь с модулем " Введение в контейнеры Docker ".

В последнем разделе, фирменное оформление, выполняется персонализация действия в GitHub Marketplace, если вы решили опубликовать его там.

Полный список метаданных действия можно найти в разделе Синтаксис метаданных для GitHub Actions.

Что такое рабочий процесс GitHub Actions?

Рабочий процесс GitHub Actions — это процесс, настроенный в репозитории для автоматизации задач жизненного цикла разработки программного обеспечения, включающий GitHub Actions. С помощью рабочего процесса можно выполнять сборку, тестирование, упаковку, выпуск или развертывание любого проекта в GitHub.

Чтобы создать рабочий процесс, добавьте действия в YML-файл в каталоге .github/workflows в репозитории GitHub.

В следующем упражнении файл рабочего процесса main.yml выглядит следующим образом:

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

on: Обратите внимание на атрибут, его значение является триггером для указания при выполнении этого рабочего процесса. Здесь он запускает процесс при возникновении события push в вашем репозитории. Можно указать отдельные события, такие как on: push, массив событий, например on: [push, pull_request], или схему конфигурации событий, которая планирует рабочий процесс или ограничивает его выполнение только определенными файлами, тегами или изменениями ветви. Схема должна выглядеть примерно следующим образом:

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration doesn't affect the page_build event above
      - created

Событие срабатывает для всех типов активности, если вы не укажете конкретный тип или типы. Полный список событий и их типов действий см. в следующих статьях: События, инициирующие рабочие процессы в документации GitHub.

Рабочий процесс должен содержать хотя бы одно задание. Задание — это раздел рабочего процесса, связанного с средством выполнения. Средство выполнения может быть размещено на GitHub или в локальной среде, а задание может выполняться на компьютере или в контейнере. Вы указываете исполнителя с атрибутом runs-on:. Здесь вы указываете рабочему процессу выполнить это задание в ubuntu-latest.

Каждое задание имеет шаги, которые необходимо выполнить. В нашем примере в шаге используется действие actions/checkout@v1 для извлечения репозитория. Интересно, что значение uses: ./action-a — это путь к действию контейнера, которое вы создаете в файле action.yml.

Последняя часть этого файла рабочего процесса задает MY_NAME значение переменной для этого рабочего процесса. Помните, что действие контейнера принимало входные данные под названием MY_NAME.

Дополнительные сведения о синтаксисе рабочего процесса см. в разделе Синтаксис рабочего процесса для GitHub Actions

Ссылки на действия в рабочих процессах

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

1. Опубликованный образ контейнера Docker в Docker Hub
   Рабочие процессы могут ссылаться на действия, опубликованные как образы контейнеров Docker в Docker Hub. Эти действия контейнеризированы и включают все зависимости, необходимые для выполнения действия. Чтобы использовать такое действие, необходимо указать образ Docker в uses атрибуте шага рабочего процесса. Рассмотрим пример.

   steps:
     - name: Run a Docker action
       uses: docker://<docker-image-name>:<tag>
   

2. Любой общедоступный репозиторий
   Действия, размещенные в общедоступных репозиториях, можно напрямую ссылаться на рабочие процессы. Эти действия доступны любому пользователю и могут использоваться, указав имя репозитория и версию (Git ref, SHA или тег) в атрибуте uses . Рассмотрим пример.

   steps:
     - name: Use a public action
       uses: actions/checkout@v3
   

[!ВАЖНО]

Для повышения безопасности используйте полную фиксацию SHA при ссылках на действия, а не только тег, например @v3.
Это гарантирует, что рабочий процесс всегда использует тот же код, даже если действие обновляется или изменяется позже.
Пример: uses: actions/checkout@c2c1744e079e0dd11c8e0af4a96064ca4f6a2e9e

3. Тот же репозиторий, что и файл рабочего процесса
   Вы можете ссылаться на действия, хранящиеся в том же репозитории, что и файл рабочего процесса. Эта функция полезна для пользовательских действий, относящихся к проекту. Чтобы ссылаться на такие действия, используйте относительный путь к каталогу действия. Например:

   steps:
     - name: Use a local action
       uses: ./path-to-action
   

Дополнительные сведения см. в руководстве по обеспечению безопасности для GitHub Actions.

4. Корпоративная marketplace
   Если ваша организация использует GitHub Enterprise, вы можете ссылаться на действия из частной платформы вашего предприятия. Эти действия курируются и управляются организацией, обеспечивая соответствие внутренним стандартам. Например:

   steps:
     - name: Use an enterprise marketplace action
       uses: enterprise-org/action-name@v1
   

Замечание

• Также можно ссылаться на действия в частных репозиториях, но для них требуются надлежащие проверки подлинности и разрешения.
• При ссылках на действия всегда укажите версию (Git ref, SHA или тег), чтобы обеспечить согласованность и избежать непредвиденных изменений.

Дополнительные сведения см. в разделе "Ссылки на действия" в рабочих процессах.

Средства выполнения тестов, размещенные в GitHub, и локальные средства выполнения

Мы вкратце упомянули, что гонщики ассоциируются с работой. Раннер — это просто сервер, на котором установлено приложение GitHub Actions. В предыдущем примере рабочего процесса в блоке заданий был атрибут runs-on: ubuntu-latest, который указывал рабочему процессу, что задание будет выполняться на сервере GitHub, работающем в среде ubuntu-latest.

Когда речь идет о раннерах, есть два варианта, из которых можно выбрать: раннеры, размещенные на GitHub, или собственные раннеры. При использовании GitHub-размещенного средства выполнения каждое задание выполняется в новом экземпляре виртуальной среды. Определяемый вами тип запуска, размещенный на GitHub, runs-on: {operating system-version}, указывает на эту среду. Если вы используете самостоятельно размещаемые агенты, необходимо применить метку 'self-hosted', операционную систему и архитектуру системы. Например, спецификация локального средства выполнения с операционной системой Linux и архитектурой ARM32 будет выглядеть следующим образом: runs-on: [self-hosted, linux, ARM32].

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

Действия GitHub могут иметь ограничения на использование

GitHub Actions имеет некоторые ограничения на использование, в зависимости от вашего плана GitHub и от того, используются ли ваши runners на сервере GitHub или на собственном сервере. Дополнительные сведения об ограничениях использования см. в разделе Ограничения использования, выставление счетов и администрирование в документации GitHub.

Размещенные в GitHub более крупные средства выполнения

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

Размеры и метки runner

Более крупные исполняющие единицы доступны в нескольких конфигурациях, предоставляя расширенные вЦП, ОЗУ и SSD-хранилище для удовлетворения различных требований к рабочим процессам. Эти конфигурации идеально подходят для таких сценариев, как:

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

Чтобы использовать более производительный исполнителя, укажите нужную метку исполнителя в атрибуте runs-on вашего файла рабочего процесса. Например, чтобы использовать исполнитель с 16 виртуальными процессорами и 64 ГБ ОЗУ, необходимо настроить runs-on: ubuntu-latest-16core.

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

Эти укрупнённые средства выполнения поддерживают совместимость с существующими рабочими процессами, предоставляя те же предустановленные инструменты, что и стандартные ubuntu-latest средства выполнения.

Дополнительные сведения о размерах runner для более крупных runner см. в документации по GitHub.

Управление большими бегунами

GitHub предоставляет инструменты для эффективного управления крупными процессами выполнения, обеспечивая оптимальное использование ресурсов и управление затратами. Ниже приведены некоторые ключевые аспекты управления большими бегунами:

Мониторинг использования

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

Управление доступом

Чтобы управлять доступом к более мощным исполнителям, можно настроить правила на уровне репозитория или организации. Эта конфигурация гарантирует, что только авторизованные рабочие процессы или команды могут использовать эти средства выполнения с высоким уровнем ресурсов.

Управление затратами

Более крупные бегуники несут дополнительные расходы на основе их использования. Чтобы управлять затратами, рассмотрите следующие предложения:

• Используйте более крупные бегуны только для рабочих процессов, требующих высоких ресурсов.
• Сокращение среды выполнения путем оптимизации рабочих процессов.
• Регулярно отслеживайте сведения о выставлении счетов для отслеживания расходов.

Масштабирование рабочих процессов

Если для ваших рабочих процессов требуется часто использовать крупные исполнители, рассмотрите стратегии масштабирования, такие как:

• Использование самостоятельно размещенных исполнителей для прогнозируемых рабочих нагрузок.
• Разделение рабочих процессов на более мелкие задания для распределения нагрузки между стандартными исполнителями.