Actions checkout v2 что делает

Кросс-платформенная сборка с GitHub Actions

Если проект живет на GitHub, можно за десять минут настроить авто-сборку под основные операционные системы — Windows, Linux и macOS.

Раньше для сборки почти всегда использовали Travis CI, многие по инерции и сейчас так делают. Но есть способ лучше — GitHub Actions.

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

Вот как это работает:

1. Создаете файл конфигурации.

mkdir -p .github/workflows touch .github/workflows/build.yml 

1. Указываете условия запуска сборки.

Например, собирать при каждом коммите:

on: push 

Или только из новых тегов:

on:  push:  tags:  - "*" 

1. Перечисляете операционные системы.

runs-on: $> strategy:  matrix:  include:  - os: ubuntu-latest  - os: windows-latest  - os: macos-latest 

1. Указываете шаги сборки.

- uses: actions/checkout@v2  - name: Build for Linux  if: matrix.os == 'ubuntu-latest'  run: gcc -fPIC -lm -shared src/stats.c -o dist/sqlite3-stats.so  - name: Build for Windows  if: matrix.os == 'windows-latest'  run: gcc -fPIC -lm -shared src/stats.c -o dist/sqlite3-stats.dll  - name: Build for macOS  if: matrix.os == 'macos-latest'  run: gcc -fno-common -dynamiclib src/stats.c -o dist/sqlite3-stats.dylib 

Действие actions/checkout скачивает исходники, а на остальных шагах выполняются те команды, что указаны по тексту. В примере это сборка исходного кода на C с помощью gcc , но у вашего проекта может быть npm run для JS или tox для Python — то, что обычно используете для сборки.

Если для вашего языка есть стандартный репозиторий пакетов вроде npm или pypi — здесь же можно опубликовать сборку. Если репозитория нет, можно опубликовать прямо на гитхабе с помощью действия svenstaro/upload-release-action :

- name: Upload binaries to release  uses: svenstaro/upload-release-action@v2  with:  repo_token: $>  file: dist/$>  asset_name: $>  tag: $> 

• Полный пример конфигурации

1. Коммитите изменения, пушите и наблюдаете результат на вкладке Actions репозитория на Гитхабе.

Готово! Теперь Гитхаб трудится, а вы отдыхаете.

• Документация по GitHub Actions
• Как сделать все что угодно вообще с GitHub Actions

Подписывайтесь на канал, чтобы не пропустить новые заметки ��

GitHub Actions: Простой способ развернуть множество стендов фронтенд-приложения

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

Можно выделить следующие преимущества GitHub Actions среди других CI инструментов:

• модульность – сообществом поддерживаются пакеты для узких задач, избавляющие вас от дублирования кода и написания длинных скриптов (примеры: сборка Docker контейнера, передача файла на сервер, оповещение в Telegram и тысячи других)
• цена – бесплатный тарифный план покроет нужды небольших проектов
• скорость – быстрее бесплатных аналогов исходя из личного опыта

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

1. Пользователь вносит изменения в ветку
2. Автоматически запускается отвечающий за сборку скрипт
3. Собранное приложение доставляется на сервер и доступно по адресу .app.example.ru

Подготовка сервера

Все действия будут выполнены на OC Ubuntu 20.04. Также нам понадобится доступ к NS-записям домена.

Подойдет cамая минимальная конфигурация, достаточная для раздачи статики. Остальную работу на себя возьмут серверы Гитхаба.

P.S.: Читателям статьи VScale предоставили купон VCGUIDE на 250 рублей.

Авторизуемся сгенерированным паролем с помощью командной строки или любого SSH клиента:

Установка необходимых пакетов

Установим nginx – он будет отвечать за раздачу файлов приложения:

apt update && apt install nginx -y

Далее создадим SSH-ключ, который понадобится нам для деплоя приложения на сервер:

ssh-keygen -t rsa -b 4096 -f deploy

Нам будет предложено задать секретный пароль, пропустим этот шаг (Enter).

Добавим ключ в доверенные:

cat ~/deploy.pub >> ~/.ssh/authorized_keys

И перезапустим сервис sshd для применения изменений:

service sshd reload
Настройка репозитория
Secrets (Settings > Secrets)

Подходит для хранения приватной информации – например, нашего SSH-ключа. Значения этих переменных будут скрыты из вывода в консоль и будут доступны только нам.

Задаем следующие переменные в настройках:

• DEPLOY_SERVER_HOST – IP вашего сервера
• DEPLOY_SERVER_PORT – SSH порт (по умолчанию 22)
• DEPLOY_SERVER_USERNAME – Имя пользователя (по умолчанию root)
• DEPLOY_SERVER_KEY – Секретная часть сгенерированного ранее ключа (посмотреть можно командой cat ~/deploy)

Github Actions: Создаем Workflow

Создадим в нашем репозитории шаблон для задачи, отвечающей за деплой:

name: CI on: [push] env: DEPLOY_PATH: /var/www/app # В теории можно собрать не только Vue-приложение, так как принцип сборки мало где отличается BUILD_SCRIPT: npm run build BUILD_SCRIPT_OUTPUT: dist jobs: deploy: runs-on: ubuntu-latest steps: # Делаем checkout текущей ветки — uses: actions/checkout@v2 # Устанавливаем Node.JS для сборки приложения — uses: actions/setup-node@v1 with: node-version: ’14’ # Записываем в переменные окружения имя текущей ветки # Чтобы избежать конфиликтов с URL, меняем точки на _, а слеши на минусы — name: Get branch name shell: bash run: echo «::set-env name=BRANCH_NAME::$(echo $ | sed ‘s/\//-/g’ | sed ‘s/\./_/g’)» # Устанавливаем зависимости для сборки — name: Install Dependencies run: npm i # Собираем приложение — name: Build Appliction run: $BUILD_SCRIPT # Доставляем собранное приложение на сервер — name: Deploy to Server uses: appleboy/scp-action@master with: host: $> port: $> username: $> key: $> source: $> target: $>/$> strip_components: 1 — name: Print Info run: echo «Deployed at https://$.app.example.ru/»

В примере выше используется созданный пользователем пакет appleboy/scp-action, выполняющий функцию архивирования файлов, передачу созданного архива по SSH и его распаковку на удаленном сервере.

Возле последнего коммита отображается статус последнего workflow
Настройка фронтенда
Автообновляемые бесплатные SSL-сертификаты

Для начала нужно привязать имеющийся домен к серверу.

В панеле управления доменом зададим DNS-серверы/NS-записи ns1.vscale.io и ns2.vscale.io

В настройках домена добавим новую запись *.example.ru, указывающую на IP нашего сервера:

Пример настроенных записей

Установим клиент ACME.sh для работы с Let’s Encrypt:

curl https://get.acme.sh | sh && source ~/.bashrc

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

Добавим полученный токен в переменные окружения сервера:

export VSCALE_API_KEY=

Следующая команда инициирует создание сертификатов для доменов *.example.ru и *.app.example.ru соответственно:

acme.sh —issue —dns dns_vscale -d *.example.ru -d *.app.example.ru —key-file /etc/ssl/privkey.pem —fullchain-file /etc/ssl/fullchain.pem —reloadcmd «service nginx force-reload»

Ждем окончания проверки, в случае успеха получаем такое сообщение:

——END CERTIFICATE—— [Mon Sep 14 10:03:50 UTC 2020] Your cert is in /root/.acme.sh/*.example.ru/*.example.ru.cer [Mon Sep 14 10:03:50 UTC 2020] Your cert key is in /root/.acme.sh/*.example.ru/*.example.ru.key [Mon Sep 14 10:03:50 UTC 2020] The intermediate CA cert is in /root/.acme.sh/*.example.ru/ca.cer [Mon Sep 14 10:03:50 UTC 2020] And the full chain certs is there: /root/.acme.sh/*.example.ru/fullchain.cer [Mon Sep 14 10:03:50 UTC 2020] Installing key to:/etc/ssl/privkey.pem [Mon Sep 14 10:03:50 UTC 2020] Installing full chain to:/etc/ssl/fullchain.pem [Mon Sep 14 10:03:50 UTC 2020] Run reload cmd: service nginx force-reload [Mon Sep 14 10:03:50 UTC 2020] Reload success

Настройка nginx

При каждом коммите в ветку, GitHub Action собирает приложение и отправляет его в директорию /var/www/app// у нас на сервере.

Нужно настроить сервер так, чтобы запросы к поддомену .app.example.ru указывали на соответствующую директорию.

Создадим/заменим стандартную конфигурацию nginx (/etc/nginx/sites-available/default):

server < listen 443 ssl; server_name "~^(?.*)\.app\.example\.ru$»; ssl_certificate /etc/ssl/fullchain.pem; ssl_certificate_key /etc/ssl/privkey.pem; ssl_trusted_certificate /etc/ssl/fullchain.pem; location / < root /var/www/app/$branch; try_files $uri /index.html; >>

С помощью регулярного выражения проверяется директива server_name: при соответствии правилу, значение поддомена подставляется в качестве имени root-директории, в которой находится уже собранное приложение.

Для применения изменений перезагружаем nginx:

nginx -s reload

Проверяем, всё ли получилось:

Экшены — Непрерывная интеграция (CI)

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

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

steps: - uses: actions/checkout@v3 

Отметим несколько деталей. Экшен работает как один из шагов задания. Для этого вместо ключа run используется ключ uses , за которым идет имя экшена. Откуда берется это имя? Из каталога экшенов . Причем там могут быть как встроенные Github Actions, так и созданные сторонними пользователями. Понять, что и откуда можно по имени экшена, оно соответствует структуре ссылок самого Github: имя пользователя или команды/название репозитория. Встроенные экшены находятся в команде actions.

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

У экшена могут быть параметры. Они задаются через ключ with :

steps: - uses: actions/checkout@v3 # https://github.com/actions/setup-node - uses: actions/setup-node@v3 with: node-version: '18.x' cache: 'npm' # ускоряет повторные сборки - run: npm ci - run: npm test 

А вот пример стороннего экшена , который запускает тесты на фреймворке cypress:

name: End-to-end tests on: [push] jobs: cypress-run: runs-on: ubuntu-20.04 steps: - uses: actions/checkout@v3 

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

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

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

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

Cypress.io и GitHub Actions: пошаговое руководство

Возможно, вы задавались вопросами о GitHub Actions . Он кажется сложным, но на самом деле это мощный и простой в освоении инструмент, который может вам помочь. Давайте рассмотрим, как использовать его для запуска Cypress тестов.

Формируем понимание того, что нужно делать

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

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

• запустить приложение на localhost
• запустить тесты на localhost.

Для того, чтобы сделать это на сервере GitHub Action, сначала нужно запустить проект и установить все необходимое. Также нужно определить, в каких случаях мы хотим запускать тесты (например, запускать их по требованию или каждый раз, когда появляется новый код). Так постепенно формируется план того, как будут выглядеть GitHub Action. В GitHub Actions эти планы называются «workflows».

Создание workflow

Теперь давайте создадим файл workflow. Он будет располагаться в папке .github/workflows:

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

name: e2e-tests on: [push] jobs: cypress-run: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Cypress run uses: cypress-io/github-action@v5 with: start: npm start

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

Во второй строке определяем событие, по которому должен выполняться данный сценарий. Существует множество различных событий, таких как push , pull_request , schedule или workflow_dispatch , которые позволяют запускать действие вручную. Полный список можно найти в документации GitHub Actions.

Третья строка определяет задачу или задачи, которые необходимо выполнить. Здесь мы должны определить, что нужно сделать. Если бы мы начинали с нуля, то здесь мы бы выполнили npm install для установки всех зависимостей, запуска приложения и проведения тестов на нем. Но, как вы видите, мы не начинаем с нуля, а используем заранее определенные действия.

Это одна из суперспособностей GitHub Аctions. Вместо того, чтобы создавать все самим, мы можем использовать ранее созданные макросы. Например, cypress-io/github-action@v5 запустит npm install , правильно кэширует Cypress (чтобы в следующий раз установка прошла быстрее), запустит приложение с помощью команды npm start и выполнит команду npx cypress run . И все это с помощью всего четырех строк в YAML-файле.

Мы скоро поговорим о различных конфигурациях для Cypress GitHub Action, но давайте вернемся буквально на минутку на шаг назад, чтобы упомянуть некоторые детали в задаче cypress-run . Параметр runs-on определяет, какую машину мы хотим использовать для тестов. Действие actions/checkout@v3 может показаться немного странным — зачем выполнять checkout для проекта, над которым мы сейчас работаем? На самом деле причина довольно проста. Есть много вещей, которые можно делать с помощью GitHub Actions, но которые не включают выполнение checkout репозитория. Например, отправка уведомления в Slack при появлении нового кода в удаленной ветке.

Теперь давайте сосредоточимся на том, как можно использовать GitHub Actions для улучшения workflow.

Запускать тест вручную

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

name: e2e-tests on: [worfklow_dispatch] jobs: cypress-run: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Cypress run uses: cypress-io/github-action@v5 with: start: npm start

После того, как вы настроите файл таким образом, можно перейти на GitHub и на вкладке «Actions» запустить рабочий процесс e2e-tests вручную.

Действия GitHub и Cypress Cloud

Cypress Cloud (ранее Cypress Dashboard) — это сервис для записи результатов тестов в Cypress. Он предлагает вид на тесты «с высоты птичьего полета», что помогает эффективно анализировать и поддерживать тесты. Запись результатов в сервис Cypress Cloud довольно проста. В качестве первого шага необходимо подключить проект к сервису. Это делается прямо в открытом режиме Cypress.

На этом шаге будет сгенерирован уникальный ключ, который будет использоваться для авторизации GitHub Actions для связи с облаком Cypress. Скопируйте этот ключ и добавьте его в среду в своем GitHub Project под именем CYPRESS_RECORD_KEY .

В качестве последнего шага нужно отредактировать файл workflow:

name: e2e-tests on: [push] jobs: cypress-run: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 - name: Cypress run uses: cypress-io/github-action@v5 with: start: npm start record: true env: CYPRESS_RECORD_KEY: $>

Это позволит записывать результаты в Cypress Cloud и добавит ключ Cypress в переменную окружения, чтобы программа Cypress могла его использовать.

Запись результатов в Cypress Cloud дает некоторые удивительные возможности. Вы можете просматривать скриншоты и видео из Cypress run, что может помочь отладить тесты, или вы можете посмотреть долгосрочную аналитику и проверить состояние тест-сьюта. Кроме того, есть несколько полезных интеграций. Если вы не хотите постоянно переключаться между Cypress Cloud и GitHub, отправляйте результаты тестирования прямо в GitHub.

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

Интеграция с GitHub также станет частью проверки пул-реквеста, чтобы можно было предотвратить интеграцию пул-реквеста в основную ветку, если тесты провалятся.

Параллельный запуск тестов

Cypress Cloud позволяет запускать тесты параллельно, и сразу после настройки проекта вы сможете легко разделить тесты на несколько машин. Конфигурационный файл будет выглядеть следующим образом:

name: e2e-tests on: [push] jobs: cypress-run: runs-on: ubuntu-latest strategy: fail-fast: false matrix: containers: [1, 2, 3] steps: - name: Checkout uses: actions/checkout@v2 - name: Cypress run uses: cypress-io/github-action@v4 with: start: npm start record: true parallel: true env: CYPRESS_RECORD_KEY: $> 

Эта установка запустит три машины и выполнит все steps параллельно. Флаг parallel: true обеспечит связь теста с Cypress Cloud и разделит все тесты между машинами. Cypress Cloud также позаботится об автоматической балансировке нагрузки при работе тестов, чтобы выполнение теста занимало как можно меньше времени.

Флаг fail-fast гарантирует, что GitHub не прервет работу в случае неудачного теста. Если установить это значение в true, вы рискуете оставить тест висеть на Cypress Cloud. Если вы хотите, чтобы тест в случае ошибки останавливался, это можно настроить в настройках проекта в Cypress Cloud. Там даже можно установить количество тестов, при выполнении которых запуск всех тестов будет отменен.

Параллельный запуск без Cypress Cloud

Как раз когда я писал эту статью, Глеб Бахмутов выпустил плагин, который позволяет запускать тесты параллельно без использования сервиса Cypress Cloud. Он разделит тесты на параллельные машины так же, как это сделал бы Cypress Cloud. Конфигурация довольно проста.

name: e2e-tests on: [push] jobs: cypress-run: runs-on: ubuntu-latest strategy: fail-fast: false matrix: containers: [1, 2, 3] steps: - name: Checkout uses: actions/checkout@v3 - name: Cypress run uses: cypress-io/github-action@v5 with: start: npm start env: SPLIT: $> SPLIT_INDEX: $>

Чтобы предоставить GitHub нужную информацию, необходимо установить переменные окружения SPLIT и SPLIT_INDEX . Таким образом, каждому процессу будут назначены необходимые спецификации. Решение будет приниматься автоматически, но есть способы настройки, упомянутые в файле README. Это хорошее решение для ситуаций, когда вам не нужен Cypress Cloud или у вас уже настроена собственный дашборд.

В заключение статьи приглашаем всех желающих на открытое занятие, посвященное основам популярных фреймворков для написания тестов на JavaScript — mocha и chai. Мы рассмотрим основные принципы написания тестов и узнаем, как использовать chai для создания автоматизированных тестов на JavaScript. Напишем пару unit и API тестов.

Основные темы этого открытого урока:
— Основные принципы написания тестов на JavaScript
— Изучение фреймворка mocha
— Изучение библиотеки chai
— Unit и API тесты

• javascript qa
• Cypress.io
• github actions
• автоматизация тестирования
• mocha
• chai