Github actions что это

GitHub Actions: знакомство и первые шаги

GitHub Actions — это сервис GitHub, который позволяет автоматизировать, в общем-то, любой процесс связанный с деплоем кода на продакшн сервер. Код проекта выполняется на виртуальных серверах GitHub и далее может быть доставлен туда, куда вам нужно. GitHub Actions имеет множество готовых решений начиная от уже написанных темплейтов по прогонки тестов, до шаблонов выкладки кода на продакшн. Сам сервис располагается на GitHub в верхней панели инструментов в вашем репозитории: При первом переходе во вкладку Actions — вам будет предложено выбрать одно из готовых решений или создать workflow самостоятельно. Так как мы знакомимся с этой технологией — выбираем пункт самостоятельного создания workflow. После выбора этого пункта откроется окно редактора: Здесь нас интересует верхняя строка, указывающая на расположение файла, где прописывается workflow: /.GitHub/workflows/ .yml. Почти вся работа над workflow будет происходить в yml файлах, расположенных прямо в вашем репозитории. Нужно создать следующую структуру директорий: в корне проекта создается скрытая директория .GitHub, в ней создается директория workflows и уже в ней располагаются yml файлы с workflow. Работать над workflow можно онлайн, используя встроенный в GitHub редактор или все делать локально, затем пушить проект на GitHub и отслеживать процесс выполнения workflow уже там. Мы начнем с онлайн версии редактора, а потом перейдем в терминал. Сначала разбираться с тем, что такое workflow.

Понятия GitHub Actions

Workflow — это последовательность выполнения задач или поток выполнения действий. Задачи внутри workflow называется jobs (работы), но обычно их не переводят, а так и называют — джобы. Джобы состоят из шагов (steps), которые содержат основные инструкции для выполнения workflow. Вся эта многоуровневая конструкция легко и органично отражается в yml файлах. Это мы увидим чуть позже. Workflow обычно выполняет какую-то большую задачу, например, тестирование проекта или его деплой. Workflow может быть множество, они могут выполнять параллельно, а могут последовательно, так же как и джобы. У Workflow множество опций срабатывания: он может быть вызван автоматически, вручную, может выполняться периодически по расписанию. Опции запуска workflow настраиваются индивидуально. Для начала работы с workflow, информации достаточно. Перейдем к практике и напишем простой тренировочный workflow в онлайн редакторе на GitHub. Если вы еще не работали с yml — то рекомендуем вам сначала ознакомиться с этой статьей из нашего блога, которая даст вам необходимые знания для работы с yml, а также настоятельно рекомендуем использовать какой-нибудь сервис проверки синтаксиса yml, чтобы избежать досадных ошибок. Например, мы используем вот этот простой и бесплатный онлайн-сервис.

Первые шаги работы с workflow

Откроем онлайн редактор на GitHub и начнем писать наш первый workflow. Он будет состоять из одной джобы и одного шага. Главное здесь — понять устройство и иерархию элементов workflow. Вот так будет выглядеть наш учебный workflow: name: Print workflow #Название workflow
on: workflow_dispatch #Триггер, который будет вызывать workflow

jobs: #Начало секции джобов
print_hello: #Название джоба
runs-on: ubuntu-latest #Среда выполнения джоба

1. Настройки самого workflow:
   • name — название workflow, которое будет отражено в дашборде GitHub;
   • on — условие срабатывания workflow. Сейчас у нас установлено значение workflow_dispatch — ручной запуск workflow. Обычно это значение установлено как push — автоматическое выполнение workflow при загрузке файлов в репозиторий;
2. Jobs — настройка джобов:
   • print_hello — название джобы. В данном случае — это print_hello;
   • runs-on — инструкция, указывающая на какой ОС запускать джобу. В данном случае джоба будет выполняться на Ubuntu последней версии.
3. Steps — настройка шагов выполнения джобы:
   • name — название шага;
   • run — действие, которое будет выполнено в терминале Linux. В нашем случае мы вызываем команду echo, которая выводит в терминал «Hello world!».

После написания workflow, его нужно сохранить путем создания коммита, так как по факту мы пишем простой yml-файл, который нужно сохранить в директорию проекта .GitHub/workflows/, чтобы workflow сработал:

Далее возвращаемся во вкладку Actions, которая теперь выглядит по другому:

Теперь слева мы видим список workflow, а в центральной части отражается условие выполнения workflow. В нашем случае, мы указали условию on свойство workflow_dispatch, что означает ручной запуск, именно поэтому у нас есть кнопка запуска workflow. После нажатия на кнопку Run workflow, мы можем переместиться в раздел All workflow и увидеть статус выполнения, запущенного workflow:

Если кликнуть по названию workflow — откроются развернутые сведения о выполненных джобах и шагах. Обратите внимание, на строки выделенные красным квадратом:

На скриншоте выделен шаг с названием Print Hello, командой, которая выполнялась и результатом выполнения этой команды. Напомним, что мы выполняли инструкцию run, которая запускала команду echo «Hello world».

Хорошо, первые шаги сделаны. Усложним немного наш workflow и добавим несколько новых джобов и шагов, а также познакомимся поближе с механизмом выполнения джобов.

Знакомимся с потоком выполнения джобов

Добавим в workflow еще несколько простых джобов, которые также будут выводить информацию в терминал:

name: Print workflow #Название workflow
on: workflow_dispatch #Триггер, который будет вызывать workflow

jobs: #Начало секции джобов

print_hello: #Начало секции первой джобы
runs-on: ubuntu-latest #Среда выполнения джоба
steps: #Начало секции шагов
— name: Print hello #Название шага
run: echo «Hello world!» #Команда, которая будет выполнена в терминале

print_full_technical_info: #Начало секции второй джобы
runs-on: ubuntu-latest #Среда выполнения джоба
steps: #Начало секции шагов
— name: Print full_tech_info #Название шага
run: sudo lshw #Команда, которая будет выполнена в терминале

print_short_technical_info: #Начало секции третий джобы
runs-on: ubuntu-latest #Среда выполнения джоба
steps: #Начало секции шагов
— name: Print short_tech_info #Название шага
run: sudo lshw -short #Команда, которая будет выполнена в терминале

Сохранив изменения, запустив workflow и, перейдя в раздел отражения статусов workflow — мы увидим, что все джобы успешно отработали за 3c.:

Если вы перейдете во внутрь джобы — вы увидите результат работы команд в терминале. Ознакомьтесь с результатом работы команды sudo lshw -short (джоба print_short_technical_info) — команда выводит в терминал сведения о VM, на которой выполняется джоба. По умолчанию джобы выполняются параллельно и независимо друг от друга.

Мы можем управлять поведением выполнения джобов, чтобы выстроить джобы в один общий поток — нужно добавить инструкцию needs: на уровень условий выполнения джобы:

name: Print workflow #Название workflow
on: workflow_dispatch #Триггер, который будет вызывать workflow

jobs: #Начало секции джобов

print_hello: #Начало секции первой джобы
runs-on: ubuntu-latest #Среда выполнения джоба
steps: #Начало секции шагов
— name: Print hello #Название шага
run: echo «Hello world!» #Команда, которая будет выполнена в терминале

print_full_technical_info: #Начало секции второй джобы
needs: print_hello
runs-on: ubuntu-latest #Среда выполнения джоба
steps: #Начало секции шагов
— name: Print full_tech_info #Название шага
run: sudo lshw #Команда, которая будет выполнена в терминале

print_short_technical_info: #Начало секции третий джобы
needs: print_full_technical_info
runs-on: ubuntu-latest #Среда выполнения джоба
steps: #Начало секции шагов
— name: Print short_tech_info #Название шага
run: sudo lshw -short #Команда, которая будет выполнена в терминале

В дашборде GitHub такой поток связанных задач, будет выглядеть вот так:

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

name: Release #Наименования текущего workflow
on: #Секция условий выполнения текущего workflow
workflow_run: #Условия запуска текущего workflow
workflows: [«Run Tests»] #Workflow, который запускается первым
branches: [main] #Ветка, в которой запускается первый workflow
types: #Тип результата выполнения первого workflow
— completed #Триггер статуса выполнения первого workflow

Отлично, теперь мы знаем как работает workflow, джобы и шаги. Настало время познакомиться с еще одной концепцией GitHub Action — экшенами.

Экшены

До этого в шагах мы использовали инструкцию run для вызова Linux команд. Однако в рамках шагов можно использовать готовые модули или решения, написанные другими пользователями для выполнения каких-то типовых задач. Такие готовые решения в GitHub называются actions или экшены. Они распространяются бесплатно и находятся в GitHub Marketplace.

Покажем на реальном примере, как искать и использовать экшены. Одна из распространенных задач — это загрузка репозитория на VM. По умолчанию у виртуальных машин GitHub нет доступа к репозиторию — его нужно разрешить. Для этого используют готовый экшен: actions/checkout@v3. Вызываются экшены через инструкцию uses.

Переходим в маркетплейс и вводим в поиск checkout. Мы получили список доступных экшенов с совпадением по искомой фразе:

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

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

name: Print workflow
on: workflow_dispatch

jobs:
checkout:
runs-on: ubuntu-latest
steps:
— name: checkout_repo
uses: actions/checkout@v3

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

О GitHub Actions и его концепциях в двух словах

GitHub Actions — это сервис автоматизации тестирования и доставки кода на продакшен. Пайплайн доставки кода, в терминологии GitHub — workflow, описывается в yml-файле и размещается непосредственно в рабочем репозитории в директории .GitHub/workflows/[work flow name].yml.

На уровне workflow определяется название workflow и триггер — условие, при котором будет срабатывать workflow. В коде эта инструкция выглядит так:

name: test_workflow #Название workflow
on: push #Триггер исполнения workflow. В данном случае workflow будет вызван автоматически при загрузке или обновления кода в репозитории.

Workflow состоит из jobs (джобы) — это логический уровень задачи. На уровне jobs определяется ОС, в среде которой будет выполняться задача и определяются шаги, которые содержат команды — инструкция run или экшены — инструкция uses. В коде это может выглядеть так:

name: print hello and checkout repo workflow
on: push

print_hello:
runs-on: ubuntu-latest
steps:
— name: Print hello
run: echo «Hello world!»

checkout_repo:
runs-on: ubuntu-latest
steps:
— name: checkout
uses: actions/checkout@v3

По умолчанию джобы и workflow выполняются параллельно на разных VM GitHub. Этим поведением можно управлять и выстраивать цепочки. Для последовательного и связанного выполнения джобов, в зависимых джобах используется инструкция needs: [waiting job]. Вот пример связанных джобов:

print_hello:
runs-on: ubuntu-latest
steps:
— name: Print hello
run: echo «Hello world!»

checkout_repo:
needs: print_hellow
runs-on: ubuntu-latest
steps:
— name: checkout
uses: actions/checkout@v3

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

Перед прочтением следующей статьи, мы рекомендуем ознакомиться с предыдущими материалами:

Git: установка, настройка, инициализация репозитория

Разбираемся с основами git: устанавливаем git на Linux, создаем репозиторий и делаем первые коммиты.

Git: коммиты, ветки и перемещение между ними

Рассматриваем подробно работу с коммитами, ветками и перемещением между ними.

Git: работа с GitHub

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

GitHub Actions — Непрерывная интеграция (CI)

GitHub Actions — бесплатная для публичных репозиториев система непрерывной интеграции. Хекслет использует Actions во всех своих закрытых и открытых проектах ( пример ). С помощью Github Actions можно делать много полезного:

• Запустить проверку кода линтером и тестами
• Выполнить деплой проекта
• Опубликовать новую версию пакета
• Подключить оповещения в мессенджер о событиях в репозитории (новые issue, PR)
• и многое другое

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

Общий принцип работы Github Actions такой: в нужном репозитории создается директория .github/workflows. Внутри нее размещаются файлы с описанием шагов, которые нужно выполнить на различные действия. Ниже описание процесса «hello-world», который запускается на пуш в репозиторий. В терминах Github Actions такое описание процесса называется воркфлоу. В нем определяется, на какие события реагировать и что конкретно делать:

# file: .github/workflows/hello-world.yml name: hello-world # on – определяет события, которые запускают воркфлоу on: push jobs: # build – произвольно выбранное имя задания # их может быть больше одного build: # операционная система для работы воркфлоу runs-on: ubuntu-latest steps: # список шагов, которые надо выполнить # экшен — выполняет какую-то задачу # checkout — клонирует репозиторий - uses: actions/checkout@v3 # run – произвольная bash-команда # ls -la выведет содержимое текущего репозитория - run: ls -la 

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

Основные понятия

На картинке ниже показаны основные концепции GitHub Actions. Разберем их по порядку.

• Воркфлоу / Workflows Каждый репозиторий на GitHub может содержать один или несколько воркфлоу. Каждый воркфлоу определяется в отдельном файле конфигурации в каталоге репозитория .github/workflows. Несколько воркфлоу могут выполняться параллельно.
• События / Events Воркфлоу может запускаться одним или несколькими событиями. Это могут быть внутренние события GitHub (например, пуш, релиз или пул-реквест), запланированные события (запускаются в определенное время — например, cron) или произвольные внешние события (запускаются вызовом Webhook API GitHub).
• Задания / Jobs Воркфлоу состоит из одного или нескольких заданий. Задание содержит набор команд, которые запускаются вместе с рабочим процессом. По умолчанию при запуске воркфлоу все его задания выполняются параллельно, однако между ними можно определить зависимость, чтобы они выполнялись последовательно.
• Раннеры / Runners Каждое задание выполняется на определенном раннере — временном сервере на GitHub с выбранной операционной системой (Linux, macOS или Windows). Также существуют автономные раннеры , которые позволяют создать свое окружение для выполнения экшена.
• Шаги / Steps Задания состоят из последовательности шагов. Шаг — это либо команда оболочки (shell command), либо экшен (action). Все шаги задания выполняются последовательно на раннере, связанном с заданием. По умолчанию в случае сбоя шага все следующие шаги задания пропускаются.

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

Общие сведения о GitHub Actions

Изучите основы GitHub Actions, включая основные понятия и основную терминологию.

В этой статье

Overview

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.

GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.

The components of GitHub Actions

You can configure a GitHub Actions workflow to be triggered when an event occurs in your repository, such as a pull request being opened or an issue being created. Your workflow contains one or more jobs which can run in sequential order or in parallel. Each job will run inside its own virtual machine runner, or inside a container, and has one or more steps that either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

Workflows

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.

Workflows are defined in the .github/workflows directory in a repository, and a repository can have multiple workflows, each of which can perform a different set of tasks. For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.

You can reference a workflow within another workflow. For more information, see «Reusing workflows.»

For more information about workflows, see «Using workflows.»

Events

An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from GitHub when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow to run on a schedule, by posting to a REST API, or manually.

For a complete list of events that can be used to trigger workflows, see Events that trigger workflows.

Jobs

A job is a set of steps in a workflow that is executed on the same runner. Each step is either a shell script that will be executed, or an action that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.

You can configure a job’s dependencies with other jobs; by default, jobs have no dependencies and run in parallel with each other. When a job takes a dependency on another job, it will wait for the dependent job to complete before it can run. For example, you may have multiple build jobs for different architectures that have no dependencies, and a packaging job that is dependent on those jobs. The build jobs will run in parallel, and when they have all completed successfully, the packaging job will run.

For more information about jobs, see «Using jobs.»

Actions

An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from GitHub, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.

You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.

For more information, see «Creating actions.»

Runners

A runner is a server that runs your workflows when they’re triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows; each workflow run executes in a fresh, newly-provisioned virtual machine. GitHub also offers larger runners, which are available in larger configurations. For more information, see «About larger runners.» If you need a different operating system or require a specific hardware configuration, you can host your own runners. For more information about self-hosted runners, see «Hosting your own runners.»

Create an example workflow

GitHub Actions uses YAML syntax to define the workflow. Each workflow is stored as a separate YAML file in your code repository, in a directory named .github/workflows .

You can create an example workflow in your repository that automatically triggers a series of commands whenever code is pushed. In this workflow, GitHub Actions checks out the pushed code, installs the bats testing framework, and runs a basic command to output the bats version: bats -v .

1. In your repository, create the .github/workflows/ directory to store your workflow files.
2. In the .github/workflows/ directory, create a new file called learn-github-actions.yml and add the following code.

name: learn-github-actions run-name: $> is learning GitHub Actions on: [push] jobs: check-bats-version: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v3 with: node-version: '14' - run: npm install -g bats - run: bats -v

name: learn-github-actions run-name: $ github.actor >> is learning GitHub Actions on: [push] jobs: check-bats-version: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v3 with: node-version: '14' - run: npm install -g bats - run: bats -v 

Your new GitHub Actions workflow file is now installed in your repository and will run automatically each time someone pushes a change to the repository. To see the details about a workflow’s execution history, see «Viewing the activity for a workflow run.»

Understanding the workflow file

To help you understand how YAML syntax is used to create a workflow file, this section explains each line of the introduction’s example:

Beside Inline

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead. name: learn-github-actions # Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)." run-name: $> is learning GitHub Actions # Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." on: [push] # Groups together all the jobs that run in the `learn-github-actions` workflow. jobs: # Defines a job named `check-bats-version`. The child keys will define properties of the job. check-bats-version: # Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)" runs-on: ubuntu-latest # Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script. steps: # The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code. - uses: actions/checkout@v4 # This step uses the `actions/setup-node@v3` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`. - uses: actions/setup-node@v3 with: node-version: '14' # The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package. - run: npm install -g bats # Finally, you'll run the `bats` command with a parameter that outputs the software version. - run: bats -v

name: learn-github-actions

Optional — The name of the workflow as it will appear in the «Actions» tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.

run-name: $ github.actor >> is learning GitHub Actions

Optional — The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository’s «Actions» tab. This example uses an expression with the github context to display the username of the actor that triggered the workflow run. For more information, see «Workflow syntax for GitHub Actions.»

on: [push]

Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see «Workflow syntax for GitHub Actions.»

 jobs:

Groups together all the jobs that run in the learn-github-actions workflow.

 check-bats-version:

Defines a job named check-bats-version . The child keys will define properties of the job.

 runs-on: ubuntu-latest

Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see «Workflow syntax for GitHub Actions»

 steps:

Groups together all the steps that run in the check-bats-version job. Each item nested under this section is a separate action or shell script.

 - uses: actions/checkout@v4

The uses keyword specifies that this step will run v4 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository’s code.

 - uses: actions/setup-node@v3 with: node-version: '14'

This step uses the actions/setup-node@v3 action to install the specified version of the Node.js. (This example uses version 14.) This puts both the node and npm commands in your PATH .

 - run: npm install -g bats

The run keyword tells the job to execute a command on the runner. In this case, you are using npm to install the bats software testing package.

 - run: bats -v

Finally, you’ll run the bats command with a parameter that outputs the software version.

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead. name: learn-github-actions # Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)." run-name: $ github.actor >> is learning GitHub Actions # Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." on: [push] # Groups together all the jobs that run in the `learn-github-actions` workflow. jobs: # Defines a job named `check-bats-version`. The child keys will define properties of the job. check-bats-version: # Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)" runs-on: ubuntu-latest # Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script. steps: # The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code. - uses: actions/checkout@v4 # This step uses the `actions/setup-node@v3` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`. - uses: actions/setup-node@v3 with: node-version: '14' # The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package. - run: npm install -g bats # Finally, you'll run the `bats` command with a parameter that outputs the software version. - run: bats -v 

Visualizing the workflow file

In this diagram, you can see the workflow file you just created and how the GitHub Actions components are organized in a hierarchy. Each step executes a single action or shell script. Steps 1 and 2 run actions, while steps 3 and 4 run shell scripts. To find more prebuilt actions for your workflows, see «Finding and customizing actions.»

Viewing the activity for a workflow run

When your workflow is triggered, a workflow run is created that executes the workflow. After a workflow run has started, you can see a visualization graph of the run’s progress and view each step’s activity on GitHub.

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click

Actions.

In the left sidebar, click the workflow you want to see.

Next steps

GitHub Actions can help you automate nearly every aspect of your application development processes. Ready to get started? Here are some helpful resources for taking your next steps with GitHub Actions:

• For a quick way to create a GitHub Actions workflow, see «Using starter workflows.»
• For continuous integration (CI) workflows to build and test your code, see «Automating builds and tests.»
• For building and publishing packages, see «Publishing packages.»
• For deploying projects, see «Deployment.»
• For automating tasks and processes on GitHub, see «Managing issues and pull requests.»
• For examples that demonstrate more complex features of GitHub Actions, including many of the above use cases, see «Examples.» You can see detailed examples that explain how to test your code on a runner, access the GitHub CLI, and use advanced features such as concurrency and test matrices.

Автоматизация рутинных задач с помощью GitHub Actions

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

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

Что такое GitHub Actions

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

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

Как описать сценарий

Файлы сценариев — workflow — хранятся в директории .github/workflow в репозитории вашего проекта. Это конфигурационные файлы формата YAML.

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

name: . on: . jobs: .

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

Каждый шаг может быть как набором bash-команд, так и готовым action.

Для примера рассмотрим сценарий, который собирает фронтенд для сайта codex.so в режиме production и добавляет сборку в пулл-реквест.

# Имя сценария name: Build frontend # Условия для выполнения: любые действия с пулл-реквестом on: [pull_request] # Список задач jobs: build: # Название задачи name: Build frontend # Выполнить на вирутальной машине с Ubuntu runs-on: ubuntu-latest # Список шагов steps: # Использовать код проекта из определенного коммита # По умолчанию используется ветка, изменения которой вызвали выполнение сценария — uses: actions/checkout@v2 # Настройка Node.js 15 для работы на виртуальной машине — name: Use Node.js 15 uses: actions/setup-node@v1 with: node-version: 15 # Установка node-пакетов проекта и сборка фронтенда # Выполнятся описанные bash-команды — name: Go to app dir, Install Node.js packages, Build static files run: cd www && yarn && yarn build # Попытка закоммитить обновления сборки фронтенда в ветку от имени бота github-actions (указываем его имя и почту с идентификатором официального бота от гитхаба) — uses: EndBug/add-and-commit@v7 with: author_name: github-actions author_email: 41898282+github-actions[bot]@users.noreply.github.com message: ‘Build frontend’

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

Локальное тестирование правильности работы сценариев не предусмотрено.

Где искать экшены

Попробуйте найти нужное действие в каталогах, перед тем, как создавать и публиковать свое собственное.

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

GitHub Marketplace: actions to improve your workflow
Find the actions that help your team build better, together.

Также стоит уделить внимание и неофициальному каталогу интересных действий — Awesome Actions.

sdras/awesome-actions
A curated list of awesome actions to use on GitHub — sdras/awesome-actions

Здесь можно найти много интересных решений и вдохновиться — возможно, у вас есть похожая задача, а вы и не думали, что её можно тоже автоматизировать.

Как написать свой Action

Допустим, вы не нашли готовое решение для нужного шага, а описать весь набор команд в виде bash-скрипта неудобно или не представляется возможным. В таком случае Вы можете воспользоваться инструкцией от GitHub. Код action может быть написан на JavaScript, собран в виде готового Docker-образа с любым содержимым. Также набор шагов может быть описан в файле в виде списка консольных команд.

Однако надо помнить, что actions на основе докер-контейнеров могут быть запущены только на виртуальной машине с Linux.

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

В качестве примера разберем codex-team/action-nodejs-package-info — действие, которое получает информацию о названии приложения и его версии из package.json файла.

Настройки хранятся в файле action.yml в корне проекта.

# Мета-информация об action используется для формирования карточки в маркетплейсе # Имя действия name: ‘Get package info’ # Описание description: ‘Action for getting information from package.json file’ # Иконка и ее цвет фона branding: icon: ‘box’ color: ‘red’ # Параметры, которое могут или должны быть переданы на вход inputs: path: description: ‘Path to package.json file’ required: false default: ./ # Параметры, которые будут доступны по результатам выполнения шага outputs: name: description: ‘Package name’ version: description: ‘Package version’ npmjs-link: description: ‘Link to npmjs.com package page’ # Условия запуска кода runs: # Описание среды и ее версии using: ‘node12’ # Пусть к собранному скрипту main: ‘dist/index.js’

Далее, для работы кода вам потребуется установить пару практически обязательных node-зависимостей:

• @actions/core — базовые функции для работы с настройкой переменных, логированием и экспортом значений;
• @vercel/ncc — утилита для сборки кода проекта в единственный js-файл со всеми зависимостями.

Добавим скрипт build для сборки исходного кода index.js со всеми зависимостями (например, @actions/core ) в единый файл dist/index.js .

< "name": "action-nodejs-package-info", "scripts": < "build": "ncc build index.js --minify" >, «devDependencies»: < "@actions/core": "^1.2.6", "@vercel/ncc": "^0.25.1" >>

И сам исходный файл с простой логикой. Получаем путь к package.json файлу, считываем его и экспортируем некоторые параметры.

import fs from ‘fs’; import < join >from ‘path’; const core = require(‘@actions/core’); /** * Read package.json file * @param path * @returns */ const readPackageJson = function (path) < const packageJson = fs.readFileSync(join(path, 'package.json')).toString(); return JSON.parse(packageJson); >; try < /** * Path to directory with package.json file * @type */ const path = core.getInput('path'); /** * Get data from package.json file * @type */ const packageInfo = readPackageJson(path); core.setOutput("name", packageInfo.name); core.setOutput("version", packageInfo.version); core.setOutput("npmjs-link", `https://www.npmjs.com/package/$`); > catch (error)

Команда core.getInput() получает значения импортированных переменных, а core.setOutput() экспортирует значения обратно в сценарий. Подробная информация о ключевых методах для работы с действиями доступна в описании пакета @actions/core.

Также, не забудьте добавить README.md файл с описанием работы действия и всех параметров. А перед коммитом изменений выполните команду yarn build для актуализации файла со сборкой или настройте сценарий, который будет делать это за вас.

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

Проверьте действие, использовав его в каком-нибудь сценарии. На момент написания заметки это единственный вариант тестирования корректности работы кода.

Полезные ссылки

Примеры самодельных действий

• codex-team/action-nodejs-package-info — информация об имени и версии node-пакета
• codex-team/action-check-domain — проверка срока регистрации домена и действия SSL
• codex-team/action-codexbot-notify — отправка уведомлений в чат Telegram или Slack

Примеры сценариев, которые используются в проектах CodeX

• публикация пакета в npm
• проверка стиля кода с помощью линтера
• сборка фронтенда в пулл-реквестах
• сборка и публикация докер-образа
• сборка и публикация electron-приложения
• предложение поднять версию пакета после обновления

If you like this article, share a link with your friends

Read more

We talk about interesting technologies and share our experience of using them.