Никита Соболев покажет множество функций Github Actions, поделится собственными впечатлениями и болями от первых месяцев использования, покажет, как сделать собственные инструменты.

Доклад 2019 года. Доклад интересный, полезный даже в 2021. Обратите внимание, что с 2019 года некоторые Actions могли измениться.

Ребята, привет! Меня зовут Никита Соболев — sobolevn (Nikita Sobolev) · GitHub. Я технический директор компании «We make services». У меня есть несколько традиционных вопросов для вас.

Как вы думаете, чем мы занимаемся?

Сервисами.

Совершенно верно, мы делаем сервисы. А второй традиционный вопрос – кто-нибудь слышал про такую компанию до этого момента? Три человека. Это, действительно, интересно. У нас маленькая компания. Примерно 5 человек. Но при этом я выступаю на сцене с людьми из Netflix, Google, AWS, что очень приятно.

И делаю я это выступление не просто так. Я рассказываю о том, что на самом-то деле есть очень классная и простая штука, которая называется Github Actions. И сегодня я вам про нее расскажу. Я вам расскажу о том, как можно просто и быстро автоматизировать разное, а точнее все.

• Я знаю, что на конференцию по DevOops приходят несколько типов людей. Первый тип людей – это девелоперы. В моем докладе сегодня будет много про Dev, про то, как работать с кодом; про то, как делать полезные для девелоперов штуки быстро и просто.

  
  

• Но с другой стороны мой доклад будет еще и для опсов, потому что опсы присматривают за нерадивыми девами. Они делают так, чтобы все работало и вообще они замечательные люди.

  
  

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

Все знают это лого. Это GitLab. И мы живем на GitLab, у нас все хорошо. На самом деле у меня все прекрасно с GitLab. Я не жалуюсь, есть GitLab CI, платный аккаунт. Все хорошо.

Я сначала хотел рассказать про наши инструменты, которые мы используем для работы с GitLab.

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

• У нас свои боты в GitLab CI, которые выполняются на каждый commit, на каждый pull request и т. д. У нас их там с пяток самых разных.
• У нас есть огромное количество ботов, которые выполняются в Cron, которые живут на Heroku и т. д. Их, наверное, штуки три.
• И нас есть свои собственные боты. Это большие приложения. Некоторые из них, действительно, большие приложения, некоторые из них чуть поменьше. Это монолиты, которые слушают вебхуки и живут непонятно где. Я это все поддерживаю, у нас есть инфраструктура. Один даже в Kubernetes живет. Это единственный раз, когда я про него сказал и все.

Всей этой историей я хотел бы поделиться с вами, т. е. как мы много всего сделали, и какие вещи вы можете взять, поставить себе и использовать. Это все в open source.

А потом, где-то месяца 3 назад, мне пришло письмо счастья. И в нем GitHub говорит: «Пожалуйста, примите участие в нашей закрытой Бете Github Actions». Я такой: «Пацаны, все меняется. Отменяем все. GitLab, до свидания, теперь мы будем рассказывать про Github Actions».

Многие могут задаться вопросом: «В чем разница?». Потому что эта технология новая. И я не буду вам подробно рассказывать про GitLab, потому что про GitLab многие знают, а про Github Actions расскажу подробней.

В чем между этими двумя технологиями разница концептуально? Концептуально разница в платформе и сообществе. Как вы понимаете, платформа и сообщество – это две важные составляющие одного и того же.

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

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

Кто-нибудь из вас может похвастаться тем, что у GitLab CI есть хорошая платформа? Т. е. у них нет никакой платформы для работы с ботами. Это правда. У них есть прекрасный CI, но все, что нужно автоматизировать вокруг, — это очень больно. А сообщества у GitLab нет вообще. Т. е. если вы попытаетесь загуглить «GitLab бот», то вы не найдете практически ничего. А если что-то найдете, то это, скорее всего, сделал я. Это грустная история.

А с GitHub это не так, потому что еще GitHub в приватной Бете, но у них уже есть хорошие платформы, хорошее сообщество.

Чтобы вы понимали уровень перегиба того, что сейчас происходить на Github, покажу вам смешную картинку.

На этой картинке некий бот. Пока нам не важно, что он делает. Это просто бот, который присылает pull request с обновлением зависимости. Мы сейчас будем подробно об этом говорить. Но это просто юмор. Это сложный технический юмор.

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

И мне кажется, что это, действительно, очень круто. Я, когда подавал этот доклад, у меня коленки тряслись от радости. Т. е. я большой фанат технологий. И когда я вижу что-то классное, то думаю: «Блин, как круто!». И этим чувством я хочу с вами поделиться. Мне GitHub, к сожалению, не платит, поэтому я это делаю бесплатно, поэтому я это делаю искренне.

И начну с рассказа про платформу.

Что у нас есть? Github Actions – это, действительно, большая платформа, чтобы запускать всякое.

Если у вас есть приватный репозиторий, то 2 000 минут Github Actions вам даются бесплатно вместе с этим пакетом.

Дальше идут вот такие цены.

Каждая дополнительная минута в зависимости от типа платформы: Linux, Windows, MacOs идет за определенную стоимость.

Но самое главное, что для open source это все бесплатно. Вообще все и навсегда. Это то, за что мы любим GitHub. И так как у меня там куча open source, то я очень люблю, что все бесплатно. И это круто.

Давайте перейдем к конкретике. Вот у нас есть конкретная задача: нам нужно прогнать линтер для Python проекта.

Я очень люблю линтер. Я много линтеров пишу сам, в также использую чужие.

В общем, задача понятна: прогнать линтер на существующие Python-код.

Как мы будем это делать? Вот наш проект — https://github.com/wemake-services/wemake-python-styleguide. Мы заходим в него.

Видим в главном меню кнопку «Actions». И переходим туда.

Дальше у нас появляется дефолтное окно, когда еще никакие actions не настроены и вообще ничего нет. И мы можем выбрать дефолтный набор действий.

Например, мы выбираем Python-пакет. Нажимаем эту кнопку.

У нас появляется следующий экран. На этом экране слева мы можем видеть код, который будет выполняться. Это некий YAML, который будет определять то, что вы будете делать. А справа расшифровка, что это такое.

Если вы думаете, что будут еще какие-то действия, то нет. Мы нажимаем на зеленую кнопку «Start commit» и готово.

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

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

Workflow – это высокоуровневый набор правил для того, чтобы делать какие-то действия при определенных условиях.

Job – это сущность, которая запускает какую-то задачу в рамках вашего workflow.

Step – это шаг. Т. е. один job может состоять из нескольких шагов.

Action – это тот переиспользуемый unit, который попал в название GitHub Actions, т. е. это самая минимальная часть, которую можно переиспользовать в нашем CI.

Event – это термин, который обозначает, что случилось какое-то действие. А если действие случилось, то мы запускаем какой-то конкретный workflow.

Давайте посмотрим на тот код, который сгенерировался в нашем прошлом примере с Python линтером и посмотрим, что там вообще есть. Его там было довольно много, но он был достаточно простой.

В начале мы определяем workflow. Для того чтобы определить workflow, нам потребуется несколько пунктов:

• Название.
• Event. В нашем случае мы работаем только на push.
• И также определение jobs, т. е. какие jobs у нас будут.

Первый job у нас будет build.

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

Но есть варианты выбора из Linux, MacOS и Windows, т. е. на всех трех платформах можно запускать. Если вы запустите на трех, то у вас появится матричная сборка, т. е. build matrix.

Что делаем дальше? Дальше мы определяем стратегию.

Для того чтобы у нас все это запустилось матрично, мы хотим проверить разные версии Python.

Версия python 2.7 скоро умрет, не проверяйте ее.

Проверяем 3.5, 3.6, 3.7.

А 3.8 мы не проверяем, потому что там оператор маржа.

Дальше мы определяем шаги для того, чтобы сказать, что конкретно делать надо.

Как выглядит это на практике? У нас появляется вот такое большое количество шагов. Раньше у GitHub был красивый визуализатор, но они его выпилили.

Мы можем посмотреть и потрогать то, как будет выглядеть наш CI дальше.

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

Первый шаг – это использование action, который называется checkout.

Checkout – это всегда первый action, т. е. это тот action, который копирует ваш код и делает git pull в текущую папку.

Следующий action имеет имя: «Пожалуйста, разверни мне Python» и дальше какая-то абракадабра. И использует action, который называется setup-python. Это то, что устанавливает вам Python.

Обратите внимание на эту абракадабру. Это не просто так. Это указание того, какую версию Python мы указали в нашей матрице.

Помните, что у нас вот здесь был matrix и python-version. Вот это – это тоже самое. Мы таким образом можем передавать параметры внутрь action.

И последний шаг. Мы говорим: pip install –r requirements и т. д.

Как вы понимаете, это не специфично для Python. Это может точно так же работать с Java, Ruby и т. д. Я привожу пример на Python, потому что я к нему привык.

С подготовкой мы закончили. Что здесь нужно увидеть и запомнить? Что у нас есть два ключевых слова, которые помогают нам либо использовать готовые actions – это слово uses, т. е. мы можем указать имя готового action, либо ключевое слово «run» — это значит выполнить какую-то shell-команду.

В принципе, все понятно и просто.

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

Для того чтобы это сделать, нам нужно будет дописать еще два steps.

В первом мы говорим: «Пожалуйста, установите мне flake8 (это линтер для Python) и прогоните его».

А во втором давайте еще тесты прогоним, т. е.: «Установите тесты и прогоните тесты».

Все, это полное описание того, что мы только что проделали с первого до последнего шага. Больше там ничего нет.

Теперь мы можем посмотреть на результаты. Как вы видите, тесты успешно прошли. Одни красненькие крестики. И мы можем посмотреть, что конкретно случилось.

Слева список наших workflow, а справа список workflow run, т. е. когда наш workflow запускается, создается график справа.

Мы выбираем какой-то конкретно. Нажимаем на него. Переходим.

И можем посмотреть, что внутри происходит.

Слева список jobs, а справа вывод нашего конкретного приложения. В нашем случае он ругается и говорит, что твой python-код плохой.

Этот интерфейс достаточно простой и понятный. Практически в каждом CI так.

Я бы хотел подвести промежуточный вывод. У нас инфраструктура, действительно, написана как код даже на этапе CI.

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

Видите, там даже есть слово uses, т. е. используй какую-то готовую компоненту для того, чтобы делать хорошо. Используй action для того, чтобы установить Python. Используй action для того, чтобы сделать checkout твоего кода. Используй action для чего угодно – вот основная идея, т. е. используй action, чтобы делать все, а community позаботиться о том, чтобы наполнить GitHub этими actions. А платформа GitHub позаботится о том, чтобы это все работало.

На мой взгляд, основная идея GitHub Actions – это как раз в этом, т.е. переиспользуемый код для инфраструктуры.

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

Давайте теперь посмотрим, как можно все автоматизировать с GitHub Actions. Что такое все и как это можно автоматизировать?

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

• Push, commit. Когда мы делаем push или commit, то происходят какие-то действия в нашем CI. Мы можем проверять на тесты, гонять линтеры и т. д.
• Issues, pull_request. Когда кто-то создает issues или pull_request, мы тоже можем выполнять какие-то действия. Например, проверять правописание, чтобы человек перед заказчиком не опозорился и слово «доделать» написал правильно. Или, например, он открывает pull_request, и мы можем проверить, что он открыть pull_request в нужную ветку, с нужным оформлением, с нужным названием и т. д.
• Issue_comment, label, Gollum. Также мы можем проверять, что произошло, например, какое-то действие: кто-то прокомментировал, добавил какой-то label или поправил wiki. Не знаю, почему wiki называется Gollum. У них события, которые правят wiki, называются Gollum.
• Вы можете даже onboarding привязать. Когда вы добавляете нового человека в репозиторий, у вас случается событие member, у вас может начаться onboarding.
• И еще есть событие по расписанию, есть webhook и много всего.

Но самое интересно, что можно пойти еще глубже.

И у каждого события есть не просто событие, но и тип события. Например, у pull_request. Смотрите их сколько. Я не буду их все зачитывать, но их очень-очень много.

По сути, любое изменение state pull_request создает событие с определенным типом. Вы можете сказать: «Кода pull_request готов к review, найди reviewer» и т. д.

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

Естественно, вы можно создавать свое. Основная фишка, что вы можете насоздавать своих actions и переиспользовать их внутри своих проектов.

Потребуется:

• Dockerfile.
• Action.yml.

Иногда достаточно Dockerfile, иногда достаточно action.yml. Это две основные компоненты, которые плюс-минус всегда нужны.

Давайте посмотрим на пример. Возьмем Dockerfile.

Что там будет внутри? Мы делаем не просто какую-то штуку, мы делаем реальный action, который вы можете потом найти в Marketplace. Он работает, он существует. Это настоящий action.

Это action для моего линтера. Я уже говорил, что я достаточно много линтеров пишу.

Он называется wemake-python-styleguide. И он проверяет код на то, что он соответствует нашему стандарту внутри компании.

Как это выглядит? Все очень просто. У нас есть базовый образ Python. Мы устанавливаем туда bash, потому что это зависимость инфраструктурная. Говорим: pip install wemake-python-styleguide, потому что это основная зависимость, которая будет делать логику.

И определяем entrypoint. Это, по сути, то, где будет храниться наша логика, как это выполнять. Определяем, говорим: «Entrypoint».

И вот сам entrypoint.sh. В нем я говорю: «Прогони мне линтер при помощи flake8, забери статус».

Говорю: «Сделай мне такую интересную штуку». Это GitHub специфичная вещь, попрошу вас на это обратить внимание. Мы говорим: «Задай, пожалуйста, вывод вот таким». Это специальный синтаксис для того, чтобы action знал, какой у него был вывод.

Соответственно: «Если у него статус неравен нулю, то, пожалуйста, упади, скажи, что все плохо и взорвись», чтобы CI провалился. Все, наш action готов.

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

Указать галочку: «Пожалуйста, этот релиз мне опубликуй в Marketplace». Нажать ее и готово.

Теперь давайте посмотрим, как его использовать. Использовать мы его будем вот так. У нас есть какие-то jobs, внутри них есть steps. И один из шагов будет: «Прогони, пожалуйста, мой линтер, который мы только что создали».

Мы можем указать название организации/название репозитория и @latest.

@latest означает – используй последнюю версию. На самом деле – это не лучший вариант использовать последнюю версию. Здесь ее, естественно, можно пинить: используй версию 1, 2, 2.5 и т. д.

Также можно передавать параметры. Вы часто хотите линтить не весь свой код, который у вас есть в репозитории, а какой-то subset этого кода. Например, вы говорите: «Передай мне, пожалуйста, параметр, чтобы путь был равен src».

И дальше можете сказать: «Покажи мне, пожалуйста, outputs, который сделал наш линтер».

Помните, что мы создавали outputs со специальным синтаксисом?

Вы можете outputs выдать в какой-нибудь файл log.txt, который, например, вам нужен.

Обратите внимание, что у нас есть входные и выходные параметры.

Да у нас же композиция! В чем основная идея? Если у вас есть входные и выходные параметры, то у вас появляется композиция. Вы можете спокойно делать композицию GitHub Actions, как композицию функции.

Как это будет выглядеть? Вывод первого action становится входным параметром для другого action, причем необязательно делать композицию подряд. А из-за того, что у вас есть именованные параметры, вы можете делать композицию так, как вам нужно. Это круто и очень удобно.

Теперь посмотрим на то, что такое action.yml. Action.yml – это файл с метаданными. И в этом файле с метаданными хранится информация, как называется, какая картиночка, описание и т. д. Но не только.

Имя понятно.

Мы можем указать список параметров, которые мы ожидаем. Помните, что я говорил, что у меня есть входной параметр, который называется path? Вот здесь я его определяю. У меня путь – это список путей, которые я проверяю. Он необязательный, по умолчанию точка, т. е. дефолтная директория.

Также нужно определить выводы, если мы их используем. Вывод у нас один, он называет output. И описание.

И последний момент – это то, как запускать наш GitHub Actions. В нашем случае мы будем использовать Docker. Вы можете использовать Python и т. д. Но чаше всего советуют использовать Docker, потому что есть переносимость, удобство. И передать аргументы, которые нам нужны. Все. Наш action готов, опубликован. Он полностью работают.

Но можно взять фреймворк и написать другой action.

Например, готовые npm компоненты:

• @actions/core — работает со всякими входными и выходными параметрами.
• @actions/exec – для того, чтобы запускать бэкграунд-задачи.
• @actions/io – для того, чтобы создавать файлы и папки.
• @actions/tool-cache – для того, чтобы создавать cache.
• https://github.com/actions/toolkit/tree/main/packages/github – для того, чтобы общаться с API GitHub.

И вы можете написать на этом целый фреймворк поверх и сделать супер action.

Например, я сделал action, который запрещает людям материться в pull_request. Не потому что я плохой, а потому что это весело.

Давайте посмотрим, как это делается. Сверху мы пишем в javascript два import: github и core.

А здесь мы пишем: «Пожалуйста, создай мне новый клиент GitHub от такого-то токена». И: «Посмотри, если у нас пришел eventName, который issue_comment, то, пожалуйста, проверь, что в этом issue_comment нет каких-то плохих слов».

«А если есть, то, пожалуйста, обнови комментарий, который равняется Input дефолтному с именем text».

И, соответственно, мы это можем использовать.

Как? Передать все события, в которых может случится с их подтипами.

И сказать: «Если кто-то матерится, накажи их». Давайте посмотрим, как это будет выглядеть на практике.

Кто-то пишет плохое слово. И его комментарий меняется на: «Мне очень жаль». Это весело и забавно. Вы можете себе поставить и троллить коллег. Это весело.

Вот ссылка — https://github.com/sobolevn/restrict-cursing-action. Он тоже опубликован. Вы можете посмотреть, как это работает внутри. Это демонстрационный вариант того, как можно писать свои сложные actions, которые ходят в API и делают всякое.

Естественно, можно использовать готовое. Фишка как раз в сообществе, в большом количестве проектов, в том, что можно брать и использовать.

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

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

Это приложение. Можно зайти в Marketplace и установить одной кнопкой.

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

И вот, как он будет работать. Он находит какое-то место, которое ему не нравится и говорит: «Вот здесь плохо». И создает комментарий, он говорит: «Вот тут плохо. Поправь». И говорит, что поправить. И вы можете с ним подискутировать, если вам нравится разговаривать с ботами.

Работает с любым языком или любым линтером.

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

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

Особенно удобно, если вы занимаетесь InfoSec, то там есть особые плагины для этого:

• Для Python – это наш собственный wemake-python-styleguide, который кучу ошибок в безопасности находит. А также есть bandit и dlint. Они работают с этим tool замечательно.
• Для JS – это плагин eslint-plugin-security.
• Для Elixir – это sobelow.

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

Следующий офигенный tool. Я состою в сообществе этого инструмента, но не очень активно в него коммитчу. Это Danger.

Что такое Danger? Это платформа для автоматического code review. Мы дожили, можно делать code review автоматически.

Показываю. Сначала у нас происходят push code, прогоняются линтеры, тесты. Потом работает Danger. И только потом код попадает на review человеку.

Для каких платформ это работает? Вы можете писать код для того, чтобы Danger его понял и понял, как проверять ваш другой код, на трех языках. Это Java Script, Swift и Ruby.

Я пробовал Java Script и Ruby. Swift не пробовал.

Что это такое? Давайте посмотрим. Заходите репозиторий Danger.

Видите плашку «View on MarketPlace», нажимаете на нее.

Переходите на страничку Marketplace, нажимаете «Use latest version».

Появляется такое окошко. Копируете эту штуку себе в step какого-то GitHub Actions. И все, работает.

Давайте посмотрим, как писать код.

Я часто прошу разработчиков не делать некоторые вещи. Когда эти разработчики часто делают эти ошибки, я просто вешаю в CI какую-то проверку, чтобы больше этого не говорить. Потому что, зачем, когда можно автоматизировать?

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

Соответственно, если pull_request нельзя автоматически отребейзить, т. е. там есть какие-то конфликты, то тоже упади, пусть разработчик пойдет и отребейзит и пришлет мне нормальный. Соответственно, можно упасть.

Можно не падать, а просто сделать предупреждение. Например, если человек не написал body к вашему pull_request, т. е. не написал, что он делал, но предупредил: «Может быть, ты хотел поделиться? Как-то что-то сделать?».

Или, например, у него в pull_request не закрыт никакой issues, то, в принципе, это нормально, если он опечатку поправил, а если он какую-то задачу сделал, то он, скорее всего, забыл, то пусть тоже поправит. Он не упадет, а просто предупредит.

https://www.npmjs.com/package/detect-secrets

Есть всякие полезности:

• Если у вас какие-то секреты используются в коде, и разработчики часто забывают, и коммитят туда AWS tokens, а вы их потом бьете по рукам, то есть такая автоматическая штука. Вы можете написать: «import detect-secrets» и бить их по рукам автоматически.
• Можно валидировать конфиги, что пришел валидный YAML, JSON.
• Проверять какие-то повторяющиеся действия, специфичные для вашего проекта.

Вот зачем это нужно.

Как это будет выглядеть?

Сверху будут ошибки, что ты ошибся вот здесь и вот здесь. А какие-то поправил и отметил как resolve, они ставятся с зеленой галочкой, что это поправлено.

Посерединке – warnings, которые вы просто предупреждаете.

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

Следующая штука – это вообще огонь – это Dependabot. Я везде его использую, всем его советую. Без него я уже не знаю, как жить. В 2021 году Dependabot — Security внутри платформы Github. Зайдите в Settings -> Security & analysis

Что это такое? Это штука, которая умеет автоматически обновлять пакеты с уязвимостями.

Как это происходит? Вы заходите в GitHub и видите вот такую плашку, что в вашем пакете уязвимость.

Нажимаете кнопку.

Он показывает, какие у вас уязвимости по разным уровням и т. д.

Вы нажимаете еще одну кнопочку «Пожалуйста, поправь».

Он говорит: «Хорошо» и присылает вам pull_request, где все поправилось. Готово, все работает. Больше ничего делать не надо. Прислались pull_requests, вы их приняли, все, ваше приложение безопасно.

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

Как выглядит pull_request внутри?

Он меняет версию вашего пакета, меняет hashes и все остальное.

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

Как это выглядит?

• Сначала он прочитает список ваших зависимостей, что у вас вообще установлено. Он поддерживает разные форматы, разные языки.
• Смотрит на наличие обновлений по этим пакетам.
• Делает много PR с изменениями одной зависимости.
• Ждет прогона CI.
• Готово.

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

Проверяем. Например, у нас есть JS и там установлены плагины для Eslint. И мы хотим, чтобы он нам его обновил. И он присылает нам обновление, где слева старый код, а справа новый код. Он бампнул версию, и мы теперь живем с новой версией. Круто.

Вот такие платформы поддерживаются, их очень много. Тут и Java, тут и Rust, тут и Python, тут и Docker, он умеет обновлять базовые образы, он умеет обновлять сами GitHub Actions. И даже странные языки типа Elm.

Устанавливается все тоже в один клик.

Заходите в GitHub Marketplace.

И это абсолютно бесплатно для всех. Нажимаете «Установить». Готово.

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

И я подумал, что надо как-то с этой проблемой бороться. А как с ней бороться? Автоматизировать.

И для этого есть замечательный инструмент, который называется semantic-release. Что это такое? Semantic-release состоит из нескольких шагов.

И первый шаг – это валидация сообщения к коммитам.

Вы создаете некую строку в RegEx, которая описывает, как вы можете описать сообщение к коммитам.

В нашем случае – это вот такая строка. Т. е. сначала мы можем указать, что какой-то коммит откатываем. Это опционально. Обычно мы редко откатываем коммиты, но иногда откатываем. Дальше мы указываем тип коммита. Это новая фича, новый fix, исправление документации или что-то неважное: отпечатки, refactoring или еще что-то, что не влияет на версию.

А дальше мы указываем scope, например, API, infrastructure, documentation, в общем любые scopes, которые есть в вашем проекте. Они специфичные для проекта, вы можете придумать список своих собственных или использовать готовые. У Angular есть хороший guide, как эти scopes определять.

И после коротенькое описание, на 50 символов максимум, что мы делаем в этом конкретном коммите, т. е. что он меняет.

Последние символы – это какую конкретную issues он затрагивает, потому что нам важно знать для истории с какой конкретно issues этот коммит работал.

Дальше мы ставим новый action для того, чтобы проверять, что все это действительно так. Он называется «Commitlint».

И когда мы будем присылать наши коммиты в GitHub, если мы будем не соответствовать этой версии, он будет падать и говорить: «Поправь, пожалуйста, сообщение к коммиту. Оно неверное, оно не соответствует стандарту. Вот стандарт».

Теперь мы можем переходить ко второй части – это правильно релизить. Как вы понимаете, релиз основывается на том, какие коммиты и какие изменения были сделаны от предыдущей версии.

И теперь мы можем правильно их посчитать. Как?

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

Сначала мы используем готовый компонент, который называется semantic-release/commit-analyzer. Соответственно, мы анализируем те коммиты, которые мы написали. И смотрим, какие конкретно фичи и багфиксы мы сделали.

Если мы сделали только багфиксы, то мы релизим батч-версию. Если мы добавили новые фичи, то мы релизим минорную версию. А если мы сделали какие-то изменения, которые все сломали, то мы релизим мажорную версию. Он за нас автоматически это может понять.

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

Генерируем changelog. Этот changelog мы коммитим обратно в репозиторий, чтобы он остался вместе с нами. И генерируем разные assets.

Что такое assets? Это некая переменная. Это может быть docker-образы, статические файлы, бинарники в зависимости от того, что вы релизите. Есть плагины почти под все.

Мы релизим docker-образы. Для нас assets – это docker-образ.

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

Используем эту зеленую кнопку.

И вот такой pipeline

Сначала мы копируем наш код, а потом указываем: semantic-release-action и что-то туда закладываем. Что это? Это секреты. Я привел два секрета в качестве иллюстрации.

Например, мы релизим что-то на NPM внутренне или внешне – это неважно. И здесь два секрета: GITHUB_TOKEN и NPM_TOKEN.

Что такое GITHUB_TOKEN? Это переменная, которая создается для нас автоматически на каждый PR. Мы о ней не заботимся, она такая, какая есть. Она хорошая. Мы ее не трогаем и нигде специально не делаем.

А NPM_TOKEN – это наш собственный секрет, который мы обязаны правильно определить. Как?

Заходим в настройки нашего репозитория.

Находим галочку «Settings».

Находим галочку «Secrets».

И потом находим имя секрета. Указываем имя секрета — NPM_TOKEN, значение секрета. Готово.

В нашем случае, когда мы указываем NPM_TOKEN, то все начинает заводиться и паблишить пакеты в NPM. И такие changelogs у нас генерируются.

Сверху номер версии, которая определяется автоматически. Дата. Далее список bug fixes, список features. Ссылки на коммиты. И issues, которые мы закрывает.

И то же самое с changelog. Бот за нас автоматически этот changelog закоммитит обратно. Нам ничего не надо делать.

Следующая большая сфера – это умные комментарии. Те, кто работает с GitLab плотно, наверное, знают, что в GitLab это называется «GitLab smart action». Там можно закрыть какой-то issues, написать CLOSE. Можно копию метадаты сделать какой-то конкретной issues в PR или наоборот. Там можно делать много всего слеш-командами, которые выглядят так:

На GitHub такой штуки не было. И это было больно, потому что есть повторяющиеся действия, которые очень удобно делать этими GitLab smart actions. А на GitHub никак.

Теперь с помощью GitHub Actions можно делать эти smart-комментарии. Как? При помощи переиспользуемых actions.

Давайте посмотрим, как это выглядит.

Например, мы хотим что-то отребейзить. Соответственно, мы пишем: /rebase. GitHub Actions поймал, что мы написали эту штуку. Он отребейзил наш PR. Все замечательно. Одной командой, которую мы сами не пишем, мы получили возможность использовать rebase внутри нашего репозитория. Круто.

Для того чтобы его установить, заходим в marketplace — https://github.com/marketplace/actions/automatic-rebase.

Нажимаем кнопку. Установлено.

Я это делаю для того, чтобы каждый раз показать, насколько это просто.

Мы можем также отменить какой-то коммит. Случайно что-то не то запушили, подумали, что это лишнее, можем отменить. /revert – отменяем.

Мы говорим: revert и номер коммита, который отменяет». GitHub Actions немножко подумает и отменит предыдущий коммит.

Здесь нажимаем установить и готово.

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

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

И мы можем попробовать сделать такой умный комментарий для того, чтобы деплоить. Представьте, что вы пишите: «/deploy», и все деплоится. Красота.

Давайте посмотрим, как это может выглядеть.

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

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

Готовые провайдеры:

• AWS, Azure.
• Zeit/ Now, Heroku.
• K8S, DockerSwarm, Dokku.
• Ansible, Chef, Terraform.
• Rsync. Можно даже Rsync использовать, уже есть готовый action для этого.
• Docker registry. Можно прямо в Docker registry все это релизить, если у вас дальше pipeline настроен от этого места.

Вариантов куча. Это все есть уже готовое. Все это плюс-минус как-то работает. Я думаю, что все с багами, но тем не менее. Вы можете взять и поставить, например, для Azure или Terraform и деплоить.

Естественно, есть куча вспомогательных средств. Какие? Если это Ansible, то вы можете прогнать Ansible-lint, если Terraform, то можете прогнать Format, если это Rsync, то вы можете посмотреть доступность того места, куда вы деплоите предварительно. Т. е. есть куча tooling вокруг, а именно не только сам процесс деплоя, но и предварительные шаги, чтобы проверить, что все правильно.

Приведу пример с Docker, как деплоим мы, и как я могу наш pipeline сейчас изменить и сделать при помощи GitHub Actions.

Мы возьмем готовый GitHub Action, который деплоит докер-образы.

Нажмем кнопочку. И все заработает.

Первый шаг – копируем код.

Второй шаг – делаем publish to registry.

Как мы это делаем? Мы указываем имя, в какой registry мы пушим наш DOCKER_USERNAME, DOCKER_PASSWORD и готово.

Таким образом, GitHub сам соберет образ, сам его запушит и все сделает хорошо.

Как у нас это выглядит на одном из проектов?

На одном из проектов у нас есть GitLab. У него есть registry. Из registry Drone забирает образ, начинает делать свои небольшие собственные действия. И потом куда-то деплоит.

Теперь это можно будет легко заменить на GitHub. Теперь у нас будет только GitHub. У него есть собственный registry. Тоже самое будет забирать Drone и куда-то деплоить. Красота.

Естественно, можно триггерить другие CI.

Какие? Также как мы триггерим Drone, мы можем триггерить:

• GitLab CI,
• Azure,
• Travis,
• Drone,
• Circle.

В общем, action, чтобы триггернуть другую CI, тоже есть. Иногда это бывает важной частью деплоя.

Теперь давайте рассмотрим пример с Terraform от начала до конца.

Как это будет выглядеть? У нас есть workflow, который работает на каждый PR. Допустим, мы деплоим каждый PR.

У нас будет первый action, который будет говорить: «Пожалуйста, проверь, что форматирование Terraform хорошее», потому что мы хотим держать наши файлы в консистентности, чтобы они все были красивые.

Как это будет выглядеть? Когда мы будем использовать этот action, то GitHub bot нам будет говорить: «Ты скобку здесь не там поставил. Иди и поправь скобку, а потом деплой».

Мы говорим: «Хорошо. Формат проверен, теперь создай мне базовую рабочую папку для Terraform». Создали.

И дальше говорим: «Пожалуйста, провалидируй, что у меня все правильно. Что у меня есть все переменные, все корректно, все работает».

Он говорит: «Хорошо», смотрит, а переменной myvar нет. Она нужна для деплоя, а ее нет. И говорит: «Пожалуйста, поправь. Я деплой делать пока не буду».

Говорим: «Хорошо», поправили переменную. И планируем деплой для Terraform, говорим: «Plan».

И GitHub bot пишет вот такую простыню с его plan. Он говорит, что будет что-то создавать и ресурс вот такой-то.

Круто! И осталось последнее действие. Чтобы применить этот plan, мы используем еще один готовый action, который называется «apply».

И Terraform делает apply, говорит: «Я Null сервис создал. Все хорошо. Вот тебе log».

Готово, наш проект при помощи Terraform задеплоен из GitHub Actions.

Вот ссылка на официальную штуку для Terraform — https://github.com/hashicorp/terraform-github-actions. Более актуальная ссылка — https://learn.hashicorp.com/tutorials/terraform/github-actions. Она поддерживается HashiCorp. И я думаю, что можно ею смело пользоваться.

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

А мне организаторы говорят: «Какое управление разработчиками? Тут умные люди сидят».

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

И хочу напомнить, что автоматизировать – это просто. Это главная ценность моего доклада. Я хочу передать вам идею, что автоматизировать – это не больно, не сложно и не надо лучше это делать руками. Нет, это просто и удобно. Пожалуйста, автоматизируйте, у вас есть для этого все инструменты и теперь все знания.

Важные несколько объявлений.

Во-первых, это бета! GitHub Actions – это бета.

Но сегодня утром я открыл свою почту, и мне пришло письмо счастья. Здесь очень много текста.

Ключевое: 13 ноября это станет доступно для всех. Буквально через две недельки это доступно для всех.

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

Но с 13 ноября это будет доступно для всех, что очень круто. Я думаю, что многим из вас сегодня такое письмо пришло.

Есть естественно проблемы. Если бы я про них не сказал, то было бы не очень честно.

Проблемы:

• Во-первый не работает кеш для зависимостей. Это спорная точка зрения, потому что кто-то считает, что зависимости кешировать не надо; кто-то сравнивает, сколько с кешем, сколько без, но по моим личным сравнениям Travis работает значительно быстрее с кешем, чем GitHub Actions без кеша. Ребята из GitHub об этом знают, они над этим работают.
• Самая большая проблема, которая делает для меня невозможной работу в open sourse, в том, что они никак не могут поправить проблему с origin/fork. Если ты работаешь внутри одного репозитория, то это все прекрасно работает, потому что у тебя есть права, потому что GITHUB_TOKEN, который создался, он правильный. А если человек прислал тебе PR из fork, то GITHUB_TOKEN у него от fork и к твоему репозиторию он не подходит. И поэтому, когда он пытается все эти действия выполнить он говорит: «Не достаточно прав, извините». И это большая проблема. Это достаточно частый паттерн, когда у тебя есть оригинальный репозиторий. Ты его форкаешь из него присылаешь PR. Пока это не работает, ребята тоже об этом знают. Это, действительно, для них очень важная проблема. Они ее пофиксят, я надеюсь, до 13 ноября.
• Относительно мало готовых компонентов. Тут важное слово – это относительно. Потому что относительно GitLab – их до фига, относительно того, что хочется – их мало. Хочется, чтобы на каждый чих был готовый компонент, чтобы ты собирал себе pipeline из кубиков и все работало. Пока, к сожалению, это не так. Я несколько actions параллельно делал для того, чтобы это все красиво работало.
• Не у всех есть доступ. 13.11 эту проблему исправят.
• Шутка: тесты за вас никто не напишет! Какой бы классной платформа не была – все это пока без автоматики.

Здесь есть несколько полезных ссылок:

• Первая ссылка – это основная точка входа в документацию по GitHub Actions.
• Вторая ссылка – это список тех events, которые запускают конкретный workflow в GitHub Actions.
• Третья ссылка – это список классных GitHub Actions, которые уже есть. Это не все, это список лучших. Все в Marketplace.

Специально для конференции я подготовил 2 GitHub Actions, которые мы сегодня смотрели:

• Первый – это запрещать людям материться. Это забавно.

  
  

• Второй – проверяет python-код на наличие проблем. Это полезно.

  
  

Первый написан для демонстрации при помощи JS и всяких разных готовых компонентов, а второй написан просто как docker-файл и метаинформация.

Последнее объявление. Сегодня у GitHub Actions будет второй доклад. Он будет не про GitHub Actions, но они там тоже будут. Если вам интересно, как взаимодействует GitHub Actions и Jenkins, приходите на доклад Олега. Сильно советую, Олег знает, о чем говорит. Будет интересно.

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

Спасибо! Ваши вопросы?

Ты упоминал про action обновления зависимости и сказал, что он на каждую зависимость делает отдельный PR. Можно ли в один PR это как-то объединить?

С Dependabot нельзя, но есть другая штука, которая называется RenovateJS. Я не уверен, с какими конкретно языками она работает, но у нее есть фича, что она обновляет сразу все одним. На мой взгляд, это не очень удобно, потому что, если вы обновляете сразу несколько, то вы не понимаете, где сломалось. Т. е. что-то сломалось, а где конкретно – вы не понимаете. По одному, на мой личный взгляд, удобнее.

Возможно ли как-то пропускать actions? По факту у тебя есть steps или несколько actions в step. И ты хочешь сделать skip.

Хороший вопрос. Не знаю, пока не пробовал. Но, я думаю, что как-то должно быть сделано, иначе это будет большой проблемой.

Какая альтернатива для BB script run only?

Я не знаю, я с bitbucket 100 не работал.

Когда уже Jenkins умрет?

Это к коллеге вопрос, это не ко мне.

Я увидел, что мы можем писать какие-то actions на языке программирования, можем bash скрипт в Run написать. И как я понял, ты можешь, допустим, на JS написать какой-то action, но я не понял, на каких еще языках это можно написать.

Ты можешь написать на любом языке, который можно запустить и получить статус код. Неважно на каком языке. Если ты его в Docker запакуешь, то гарантированно на любом. Но если ты хочешь использовать готовые компоненты, чтобы работать с кешем, с API и т. д., то это только Java Script/TypeScript. Вот эти два языка готовы для того, чтобы делать все быстро и хорошо.

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

Хороший очень вопрос. Я пока не могу сказать, потому что у нас пока приватные репы хранятся на GitLab. Я думаю, что некоторое время точно еще будут там храниться. Но в связи с последними гитлабовскими событиями мне хочется переехать от них, потому что телеметрию всовывать не понятно куда – это не очень хороший шаг.

На GitHub меня очень прельщает идея, что и open source, и закрытые проекты будут в одном месте. Это для меня будет очень просто, потому что сейчас, по сути, мне нужно две инфраструктуры поддерживать: одну для GitHub, другую для GitLab. Это проблематично.

Тогда, может быть, ты знаешь кого-то, кто использует на приватных репах GitHub Actions из community?

Нет, я пока таких людей не знаю.

Получается, что сторонние CI не нужны. Но, как я видел, ты Drone еще использовал?

Они не нужны. Если у вас есть какие-то сервисы, которые завязаны на этом, то можете их триггерить из GitHub CI. И это полезно в некоторых случаях. Например, у нас Drone занимается сборкой Docker и дополнительными проверками на стороне клиента. Мы пушим наш docker-образ, он его дополнительно проверяет, что там нет его собственных проблем, т. е. некий аудит происходит. И этот Drone, по сути, не наш. Это просто такая точка, которая работает, чтобы передать куда-то дальше слово, которое я обещал не говорить.

Все бесплатно. А если все платно? У тебя какой-то action стриггерился, начал работать, но начались считаться деньги, пока он работает. И ему нужно делегировать задачу в стороннюю штуку и дождаться ответа. И чтобы он не ждал синхронной, и мы не платили, пока он ждет, то мы хотим вернуть результат. Можно ли как-то это сделать?

Точно нет, потому что action – это синхронная штука. Делать асинхронные actions – это было бы неправильно. pipeline – это все-таки синхронная история.

Т. е. если мы делегируем куда-то надолго, то стоит подумать – нужно ли вообще делегировать?

Да. И нужно ли дожидаться ответа? Т. е. может быть нам ответ не важен: делегировали и делегировали, а на той стороне уже разберемся.

Ты показал, как делать кастомные actions, но может быть такая ситуация, когда тебе нужно сделать кастомный event, например. Т. е. у тебя есть корневой event, но в нем есть параметры. И ты как-то хочешь его фильтровать.

Свои events делать нельзя. Ты можешь настроить webhook. А по поводу выборки по типам events, то – да, это есть. У PR есть: открыт, закрыт, изменен, удален, назначен reviewer, изменен код и т. д. Там есть подтипы, которые помогают делать выборку.

Ты показывал кастомный UI и у тебя появилась какая плашка, кнопка. Действия на эту кнопку тоже что-то триггерят. Там есть отдельная библиотека, чтобы рисовать эти UI и компонеты, либо как происходит это кастомное рисование внутри репозитория, когда ты action подключил?

Они UI кастомный отключили. Кстати, я хотел об этом пошутить, но забыл. Есть первая версия GitHub Actions, которая написана на HSL. Там все совсем по-другому. Но о ней мы не говорим, ее не было. Это была ошибка, мы ее пропустили. Рисование было там. Там была идея, что ты можешь график делать, соединять стрелочками и т. д. Но это не зашло, потому что это аудитория разработчиков. А для аудитории разработчиков это проще в YAML описать и проверять, чем руками туда-сюда перетаскивать. Я думаю, что поэтому они это свернули.

Я имел в виду несколько другое. Мы по зависимостям что-то искали, и там сверху была какая-то кнопка толи смержить, толи подтвердить это все, толи это была какая-то стандартна кнопка внутри PR. Например, у нас есть стандартная сущность: merge_request или pull_request.

Нет, там никаких дополнительных UI нет, т. е. ничего не меняется. Появляется только новая вкладочка «Action». И внутри action новый UI, а все остальное не меняется.

Ты рассказывал про Danger и ты привел Rube, JS, Swift. И я не понял – это языки, на ка которых есть SDK?

Да, это языки, на которых ты можешь писать конфигурационный файл для Danger. Самое смешное, что он имеет разный бэкенд. Этот разный бэкенд работает с разными плагинами. Иногда ты должен выбирать по тем плагинам, которые тебе нужны. Естественно, javascript’овые имеют больше плагинов к JS, ruby’шные имеют больше плагинов к Ruby, а swift’овые – не знаю.

Расскажи подробней про сам Danger. Если есть SDK есть на этих языках, но я хочу валидировать какие-то другие проекты. Что еще можно с помощью него?

Danger – это просто язык программирования, ты можешь делать все, что угодно в нем. Другое дело, что он тебе в контекст передает какие-то метаданные о текущем контексте: в PR, issues и т. д. Ты можешь делать все.

Если тебе нужно запустить какую-то утилиту и проверить статус код, то ты говоришь: «process.execSync» в JS и, соответственно, выполняешь какой-нибудь execSync, смотришь статус и что-то делаешь.

Если тебе нужно проверить контексты, то ты просто там делаешь if, ты импортируешь 2 дополнительные функции: файл, warning и т. д. И ты их используешь. Он наполняет себя этими штуками и в конце рендерит то, что тебе нужно внутри PR, чтобы все люди увидели, что вообще происходит.

На самом-то деле там нет никакой автоматизации суперширокой. Для меня Danger – это инструмент, который умеет проверять то, что не умеют проверять линтеры. Когда статические тесты прошли, я проверяю только корректность оформления, что человек правильно все правил, что у него правильно все заполнено, что он выполнил все нормативные правила по доставке кода в виде PR.

А именно суровой проверки внутри Danger я не делаю, потому что есть другие, более подходящие для этого инструменты.

Получается, что Danger – это такая верхнеуровневая штука?

Да. И легче импортировать какой-то существующий JS-код и из него что-то сделать. Если есть линтер, то прогнал линтер.

Как защититься от открытия секретов, если в Github action написать echo secrets?

Это очень хороший вопрос. Я задавал этот вопрос и GitLab, и GitHub. И внятного ответа не получил. Почему я не использую сейчас с кастомным GITHUB_TOKEN, который имеет доступ ко всему? Я не знаю, как его люди будут использовать. Т. е. я сейчас выложу token, и люди – хоп, начнут его использовать, чтобы писать от меня комментарии, что я люблю, Go, например. Нет, я не доверяю этому. Я хочу какой-то token, который обладает ограниченными правами и желательно, чтобы он мог запускаться только из GitHub Actions. А сейчас это явная проблема. Люди будут использовать это не по назначению.

Но другое дело, если это open source и у человека нет желания точечно именно этого человека взломать и что-то сделать, то всем по фиг. Лежит там чей-то пароль и лежит. Никому не интересно. Я такие проекты видел. Я даже думал им прислать такой PR, чтобы показать, что есть уязвимость. А потом подумал: «А зачем? Работают ребята и работают, зачем им мешать?».

P.S. Чат по Github action — https://t.me/github_action_ru
Немного рекламы: На платформе https://rotoro.cloud/ вы можете найти курсы с практическими занятиями:

• Ansible для начинающих + практический опыт
• Certified Kubernetes Administrator (CKA) + практический опыт
• Docker для начинающих + практический опыт
• Kubernetes для начинающих + практический опыт
• Terraform для начинающих + практический опыт
• Практика для вхождения в IT (Linux, Docker, git, Jenkins)