Как настроить github actions

Введение в GitHub Actions

В этой статье Senior App Dev Manager Джейсон Джордано (Jason Giordano) покажет нам, как использовать GitHub Actions для создания очень простого CI/CD решения.

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

Также рекомендую ознакомиться с данной документацией перед тем, как решите расширить свое решение.

Необходимые инструменты

Начало работы:

Откройте командную строку и введите:

Для заключительного этапа (git push) мы воспользуемся GUI, чтобы продемонстрировать другой вариант работы с репозиториями Git.

Итак, первым делом откройте GitHub Desktop и нажмите “Add an Existing Repository from your hard drive…”

Теперь нажмите “Choose…”, перейдите в папку “Blog” и кликните “Select Folder”, после чего “Add repository”

Нажмите “Publish repository”

Снова нажмите “Publish repository”

Теперь кликните “View on GitHub”

Нажмите “Set up Actions”

Нажмите “Set up this workflow”

Кликните на “Start commit”, после чего “Commit new file”

Перейдите на вкладку “Actions”

Нажмите “.NET Core”, чтобы увидеть автоматическую сборку

Теперь перейдите на вкладку “Code”

Кликните по иконке “Edit this file”

Измените текст на:

Нажмите “Commit changes”

Вернитесь на вкладку “Actions”, чтобы просмотреть процесс автоматической сборки

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

Источник

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

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

Jul 13, 2020 · 6 min read

Что такое 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

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

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

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

Steps

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

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

• 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 — служебные и подставляются гитхабом автоматически. Можно не переживать, просто напишите << secrets.GITHUB_TOKEN >> и все будет работать

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

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

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

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

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

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

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

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

Источник

Github actions и кросс-платформенное построение

Привет, Хабр. Это статья о том как настроить построение на всех платформах с помощью github actions.

Предыстория

Написал я простенькое приложение на electron, сам я пользовался linux-ом но мой друг предпочитал macos. Когда я попытался скомпилировать на своём компьютере для macos и передал моему другу pkg — Оно не запустилось. В итоге оказалось единственным вариантом скомпилировать приложение для macos это скомпилировать его на macos. Для максимального упрощения задачи я сделал три скрипта: build:linux, build:mac, build:win. В результате после компиляции получались файлы: linux.deb, linux.AppImage, mac.pkg, win.exe. Но оставалось одна проблема нужно было компилировать на разных системах. И тут спасение gihub actions.

Как всё должно будет работать

Я нажимаю кнопку new release на github, а затем магия запускается workflow на github actions он компилирует на всех операционных системах и добавляя бинарники к релизу

Для добавления файлов к release я использовал https://github.com/JasonEtco/upload-to-releas, однако было одна загвоздка с этим действием. Это действие контейнерное, а в github actions контейнерные действия доступны только в linux. Поэтому было решено использовать четыре job-а, 3 для компиляции и 1 для загрузки. Так как для каждой job-ы окружение не сохраняется, по этому для обмена между ними используются артефакты

Практика

Для начала в папке .github/workflows/workflow.yml с содержимым

Ну я думаю понятно что это workflow CI и запускаться он по релизу, а теперь самое важное job

По шагам jobs: это все работы, build-linux: это работа с названием build-linux, runs-on: ubuntu-latest говорит что нужно запускать всё под последней ubuntu

А дальше самое интересное steps: и всё что под ним это то что будет делать наша работа

Во-первых — uses: ations/checkout@v1 клонирует репозиторий чтобы мы могли его использовать. Следующий шаг Install bluetooth устанавливает блютуз т. к. проект его использует. Далее устанавливается зависимости и происходит билд. Так как после построения в папке dist находятся не только бинарники, но и не нужный мусор, по этому следующим действие происходит создание другой папки в которой лежат только бинарники, а затем их загрузка в артефакты.

Почти то же самое и для win с macos

Однако стоит отметить некоторые различи. Во-первых, не нужно устанавливать блютуз он уже установлен, Однако нужно установить nodejs для этого используется actions/setup-node. Также в windows используются другие команды на этапе Creating out.

И конечно финальный этап это загрузка файлов в релиз

Очень важна часть это needs данная строка говорит о том что нужно запустить работу только после всех билдов(Если что билды идут параллельно), Затем сначала мы скачиваем артефакты, а затем бинарники из них добавляем к релизу

Источник

Автоматизация ручных действий с GitHub Actions

GitHub Actions — инструмент для автоматизации рутинных действий с вашего пакета на GitHub.

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

GitHub предоставляет действительно удобные и рабочие инструменты для этого.

План действий

настроим CI в GitHub Actions для небольшого проекта на PHP

научимся запускать тесты в матрице с покрытием (зачем это нужно также расскажу)

создадим ботов, которые будут назначать ревьюющих / исполнителей, выставлять метки для PR-s (на основе измененных файлов), а по окончании ревью и проверок в Check Suite будут автоматом мержить наши PR, а сами ветки будут удаляться автоматически.

подключим бота, который будет создавать релизы, которые автоматически будут пушиться в packagist.

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

Настройка CI

Сильно углубляться в тонкости настройки CI для запуска тестов я не буду, на хабре достаточно постов об этом, но для небольшого проекта на PHP с базой данных Postgres примера моего CI вполне хватит. Лишнее можно удалить, названия и ключи можно менять на ваш вкус.

Создайте файл примерно с таким содержимым:

Расскажу лишь в кратце, в этом конфиге 3 основных шага (lint, tests и coverage)

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

Если код не соответствует code style проекта, джобка падает и CI дальше не запускается. В данном примере, я использую линтер с правилами от umbrellio/code-style-php, а сами скрипты запуска описаны так (первый для проверки, второй для авто фиксов для локального использования):

test — тестируем наше приложение в матрице следующего ПО (os, postgres и php), а через опцию include добавляем что-то дополнительное (важно сохранить структуру ключей матрицы).

В целом тут тоже ничего нет сложного, разве что два момента:

опция experimental (к слову назвать опцию можно как угодно) для матрицы нужна для того, чтобы падающие джобки в экспериментальном окружении не фейлили CI, например, когда вы добавляете поддержку новой версии PHP, и не ставите самоцелью решать упавшие тесты или покрытие прям щас. Такие джобки игнорируются (если падают).

строки с sed -e «s/\$/$<< env.DB_USER >>/». нужны для того, чтобы переменные подключения к БД были записаны из файла phpunit.xml.dist с плейсхолдерами в phpunit.xml, это не панацея, вы можете использовать переменные окружения ENV, но на всякий случай файл доступен тут:

coverage — т.к. тестирование и покрытие также происходит в матрице, т.к. часть кода может быть написана под одну версию Postgres, а другая под другую и оформлено в виде условий в вашем коде, то покрыть на 100% за одну итерацию может быть невозможно. К сожалению, composer, в отличие от Bandler-а от Ruby, так делать не умеет.

Но т.к. я перфекционист и мне нужен badge:100% coverage, в моем случае используется матрица покрытия и затем, отправленные отчеты о покрытии, мержатся в один. Например, coveralls.io поддерживает обьединенный кавераж.

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

Авто-назначение меток (labels)

Для подключения бота создайте два файла (конфиг и скрипт):

Тут по сути мы описываем маппинг меток к файлам и директориям вашего пакета, в зависимости от того, какие файлы будут изменены в рамках вашего PR, такие метки будут автоматически выставлены к PR.

Метки нужны для того, чтобы в последствии мы могли на их основании генерировать Summary для наших релизов и определять степень важности PR (будет ли это patch, minor или major). Вообще говоря, метки помогают визуально категоризировать пулл-реквесты, что очень удобно, когда их (pull-реквестов) много.

Авто-назначение ревьюеров и исполнителей

Для подключения бота создайте два файла (конфиг и скрипт):

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

Авто-мержирование проверенных PR

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

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

Мержить будем через Squash, чтобы была красивая история коммитов.

Авто-апрув отревьюенных PR

Когда ревьюющий ставит аппрув в PR, будем автоматом проставлять метку approved, создайте файл скрипта с содержимым:

Авто-выпуск релизов с ченджлогом

Для подключения бота создайте два файла (конфиг и скрипт) с содержимым:

В зависимости от меток, бот будет увеличивать либо MAJOR, либо MINOR, либо версию PATCH

Теперь нужно провести некоторые настройки в GitHub Settings вашего проекта

Настройка Check Suite в GitHub

По умолчанию ветки в GitHub никак не ограничены, и пушить в них может каждый, кто имеет доступ на запись, но если вы хотите, чтобы код был красивый, чтобы код был покрыт на 100%, и у вас есть прочие хотелки, необходимо поставить ограничения и настроить Check Suite.

Пример, где настраиваются ограничения веток

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

Настройка approvals

По сути, тут мы настраиваем кол-во людей, которые должны посмотреть PR, будут ли сбрасываться апрувы, после появления новых коммитов, а также необходимо ли участие Code Owners в ревью.

Пример, как настраиваются approvalls

Настройка обязательных проверок для Check Suite

Все наши проверки (в CI это джобки, в основном, но и другие интеграции тоже, например, Coveralls / Scrutinizer, и прочие анализаторы кода), могут быть как обязательными или необязательными.

Если проверка обязательная, то мержирование PR будет заблокировано пока все проверки не будут пройдены.

Пример, как настроить Check Suite для ветки

Автоматически удаляем ветки после мержа

Чтобы у нас была красивая история коммитов, а также чтобы не удалять вручную ветки после мержа, в Settings => Options нужно разрешить только Squash, если вы хотите красивую историю коммитов и включить опцию «Automatically delete head branches«

Пример настройки тут

Настройка веб-хука для packagist.org

Тут все стандартно, на сайте packagist есть инструкция, но для полноты поста выложу тоже.

Пример, как настроить webhook packagist

Секретный ключ можно взять на packagist в настройках вашего профиля (Show Api Token).

Таким образом, если вы поддерживаете достаточное кол-во OpenSource проектов, и в каждом из них есть некоторое количество активных Contributor-ов (с правами записи), вы можете настроить CI так, что сообщество будет само писать код, а ваши доверенные лица будут ревьюить, общий workflow будет соблюден.

Вы даже можете в coveralls / scrutinizer настроить правила, чтобы Check Suite падал если % покрытия кода меньше 100%, а в Readme напичкать баджиками для красоты, например так:

Буду рад, если мой туториал будет кому-то полезен, т.к. перед написанием данного поста я впервые столкнулся с GitHub Actions, я не DevOps и настройкой CI не занимаюсь, самому пришлось прогуглить не один сайт, чтобы настроить такой workflow, который был нужен мне.

Источник