Github actions что это

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.

Github actions: базовые понятия

Что это такое и как удаленно прогонять тесты на каждый пуш при помощи одного крошечного конфига

6 min read
Jul 13, 2020

Что такое github actions вообще?

Это указание гитхабу запускать какой-то код каждый раз когда случается некое событие. Push, создание PR, таймер, внешнее событие, а также всякие другие.
Где запускается этот код? На виртуальных машинах гитхаба(но при желании можно и на своих гонять). Удобно, можно ничего не настраивать.
Что он делает? Да что угодно, насколько хватит фантазии, главное — позволяет автоматизировать какие-то действия, нужные для вашего процесса разработки: гонять тесты, собирать и деплоить продукты, собирать статистику, оповещать людей.

Таким образом github предоставляет возможность не только прикрутить неплохой бесплатный CI/CD(как раньше умел только gitlab, о котором у меня тоже была статья), но и создать очень гибкую и легко конфигурируемую систему поддержки разработки.

Тут все восхитительно просто.

Для начала нужно придумать, что же хочется сделать. Потом найти готовый экшен/несколько, которые позволят это сделать. Их проще всего искать в github marketplace — по сути это просто список репозиториев, которые подали заявку, чтобы быть там. На самом деле вы будете ссылаться на конкретный репозиторий конкретного пользователя.

Если подходящие готовые не находятся, всегда можно написать свой. Это очень просто. Я, например, написала экшен, чтобы интегрировать jira в пулл-реквесты:

jira-description — GitHub Marketplace

A lightweight solution to integrate GitHub with JIRA for project management. �� To make jira-description-action a part…

Пока что давайте разберем самый простой пример — пусть на каждый пуш в любой ветке гоняются тесты(пример будет про js-разработку)

В первую очередь нужно создать в своем проекте папку .github, а в ней папку. workflows, а в ней файл name-matters-only-for-you.yaml

контент у него будет такой:

name: 'test my project'
on: 
push: 
pull-request:jobs: 
test-job: 
runs-on: ubuntu-16.04 
steps: 
- uses: actions/checkout@v2 
- uses: actions/setup-node@v1 
name: 'setup node' 
with: 
node-version: '13.x'
 
- name: 'install' 
run: npm i
 
- name: 'test' 
run: npm run test

Тогда в интерфейсе гитхаба прогоны будут выглядеть вот так:

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

# имя, чтобы отображалось в интерфейсе
name: 'test my project'# тут список событий, на который экшен должен запускаться
on: 
push: # пусть гоняется на любой пуш 
pull-request: # и на пулл-реквест# список того, что нужно делать. каждый job будет выводиться отдельным элементом слева UI
jobs: 
test-job: # uniqe id 
runs-on: ubuntu-16.04 # на какой машине гонять 
steps: # список шагов, разберем подробнее отдельно ниже 
- uses: actions/checkout@v2 
. 

Steps

1. Весь конфиг пишется в yaml, поэтому важно следовать синтаксису и следить за отступами, новая сущность в списке начинается с –
2. Шаги — это по сути упорядоченный список. Они будут выполняться один за одним строго последовательно

Посмотрим еще раз на конфиг, тут видно, что у нас 4 шага, только у них почему-то разный набор параметров, как это работает?

steps: 
- uses: actions/checkout@v2 
- uses: actions/setup-node@v1 
name: 'setup node' 
with: 
node-version: '13.x'
 
- name: 'install' 
run: npm i
 
- name: 'test' 
run: npm run test

• name нужен просто для отображения в интерфейсе, без него прекрасно можно обойтись
• uses тут указываем имя какого-то уже написанного экшена, если хотим его использовать. Экшен может быть конкретным бранчем в конкретном репозитории(любом), может быть вообще кодом, лежащим в соседней папке, а может быть и вовсе docker-image(полный список)
  В примере используется actions/checkout@v2 и actions/setup-node@v1 . По названию легко можно найти их в marketplace, посмотреть исходный код конкретной версии(она идет после @ в названии) и понять, что они делают. checkout делает pull репозитория и ветки, в котором запущен. Таким образом мы получаем доступ к коду. Без этого экшена делать npm i было бы не на чем.
  setup-node устанавливает ноду, чтобы мы могли дальше использовать ее
• with если шаг использует экшен, то иногда в него хочется передать параметры. Параметры регламентированы самим экшеном. В примере мы можем указать версию ноды, необходимую для нашего проекта
• run запускает какую-то команду в shell. Использовать shell-команду вместе с экшеном не получится, они должны жить в разных шагах

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

Вот и все, разобрали маленький пример, ура, можно дерзать!
Чтобы было проще, собрала список вещей, которые узнала, когда дерзала сама

Более сложные вопросы:

Как передать какой-нибудь токен, нигде его не публикуя? Или что такое secrets в конфигах?

Всякие токены доступа, опубликованные в публичном доступе, это большой риск для вашей секьюрности. Как передавать их в зашифрованном виде? Гитхаб уже позаботился об этом, создав secrets. Их можно найти в любом репозитории: settings -> secrets. Там можно создать секрет с почти любым именем, например, MY_TOKEN, добавить к нему значение, и тогда в любом экшене можно будет написать secrets.MY_TOKEN , и это значение будет использоваться

Прикольные вещи:
1. Один раз создав и сохранив секрет, посмотреть его значение будет уже нельзя, только обновить
2. Если попытаться вывести значение секрета в логах или внутри кода экшена, выведется ***
3. Однако лучше не логгировать секреты вообще, так как любую защиту такого рода все же можно обойти

Как добавить secrets.GITHUB_TOKEN, который нужен в конфиге?

Все секреты с именами, начинающимися на GITHUB — служебные и подставляются гитхабом автоматически. Можно не переживать, просто напишите > и все будет работать

Как сделать так, чтобы нельзя было замержить пулл-реквест если тесты упали?

Нужно пойти в настройки репозитория и у становить там правила для мержа в master, выбрав галочкой workflow, содержащий важные тесты

Как передать результат работы одного шага в другой шаг?

Это очень классная фича! При помощи кода ниже я проверяю, есть ли измененные файлы после билда в папке lib и, если есть, делаю коммит с обновленной сборкой. Переменные, добавленные в шаге, доступны в любом следующем шаге этого же job

- name: "check if build has changed" 
run: echo ::set-env name=DIFF::$(git diff --stat -- 'lib')

- name: "Commit files" 
if: $> 
run: git commit -m "build action" -a

Как передать результат работы между джобами?

Тут немного веселее!

jobs: 
first-job: 
- name: "check if build has changed" 
id: has-diff 
run: echo ::set-output name=DIFF::$(git diff --stat -- 'lib')
 
outputs: 
diff_output: $>
 
second-job: 
needs: build-test 
steps: 
- name: "print diff" 
run: echo "$>"

Важно помнить, что и output, и env-параметры это строки, которые могут содержать специальные символы. Поэтому при выводе в консоль необходимо это учитывать, иначе можно получить вот такую ошибку, если написать run: echo $> без кавычек:

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