75. Обзор GitHub Actions
Содержание
Обзор действий GitHub
В этом разделе я хотел бы перейти к рассмотрению, возможно, другого подхода, чем тот, на который мы только что потратили время. На этом занятии мы сосредоточимся на GitHub Actions.
GitHub Actions - это платформа CI/CD, которая позволяет нам строить, тестировать и развертывать, помимо прочих задач, наш конвейер. В ней есть концепция рабочих процессов, которые собираются и тестируются на основе репозитория GitHub. Вы также можете использовать GitHub Actions для управления другими рабочими процессами на основе событий, происходящих в вашем репозитории.
Рабочие процессы
В целом, в GitHub Actions наша задача называется рабочий процесс.
- Рабочий процесс** - это настраиваемый автоматизированный процесс.
- Определяется как файлы YAML.
- Содержит и запускает одно или несколько заданий.
- Запускается при срабатывании события в вашем хранилище или может быть запущен вручную.
- Вы можете использовать несколько рабочих процессов для каждого хранилища.
- рабочий процесс содержит задание, а затем шаги для достижения этого задания.
- В рамках рабочего процесса у нас также будет запускающий механизм, на котором будет выполняться наш рабочий процесс.
Например, у вас может быть один рабочий процесс для создания и тестирования запросов, другой рабочий процесс для развертывания вашего приложения каждый раз, когда создается релиз, и еще один рабочий процесс, который добавляет метку каждый раз, когда кто-то открывает новую проблему.
События
События - это определенные события в хранилище, которые запускают рабочий процесс на выполнение.
Задания
Задание - это набор шагов рабочего процесса, которые выполняются на бегунке.
Шаги
Каждый шаг в задании может быть скриптом оболочки, который выполняется, или действием. Шаги выполняются по порядку и зависят друг от друга.
Действия
Повторяющееся пользовательское приложение, используемое для часто повторяющихся задач.
Бегуны
Бегунок - это сервер, который запускает рабочий процесс, каждый бегунок выполняет одно задание за раз. GitHub Actions предоставляет возможность запуска бегунов для Ubuntu Linux, Microsoft Windows и macOS. Вы также можете разместить свой собственный на определенной ОС или оборудовании.
Ниже вы можете увидеть, как это выглядит: у нас есть событие, запускающее наш рабочий процесс > наш рабочий процесс состоит из двух заданий > внутри наших заданий есть шаги, а затем действия.
YAML
Прежде чем мы приступим к рассмотрению реального случая использования, давайте взглянем на приведенное выше изображение в виде примера YAML-файла.
Я добавил #, чтобы прокомментировать, где мы можем найти компоненты рабочего процесса YAML.
#Workflow
name: 90DaysOfDevOps
#Event
on: [push]
#Jobs
jobs:
check-bats-version:
#Runners
runs-on: ubuntu-latest
#Steps
steps:
#Actions
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
Приступаем к работе с GitHub Actions
Я думаю, что у GitHub Actions есть много возможностей, да, они удовлетворят ваши потребности в CI/CD, когда речь идет о сборке, тестировании, развертывании вашего кода и последующих шагах.
Я вижу множество вариантов и других автоматизированных задач, для которых мы могли бы использовать GitHub Actions.
Использование GitHub Actions для линтинга вашего кода
Один из вариантов - убедиться, что ваш код чист и аккуратен в вашем репозитории. Это будет наш первый демонстрационный пример.
Я собираюсь использовать некоторый пример кода, связанный в одном из ресурсов для этого раздела, мы будем использовать github/super-linter для проверки нашего кода.
name: Super-Linter
on: push
jobs:
super-lint:
name: Lint code base
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Run Super-Linter
uses: github/super-linter@v3
env:
DEFAULT_BRANCH: main
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
github/super-linter Вы можете видеть, что для одного из наших шагов у нас есть действие под названием github/super-linter, которое ссылается на шаг, уже написанный сообществом. Вы можете узнать больше об этом здесь Super-Linter
“Этот репозиторий предназначен для GitHub Action для запуска Super-Linter. Это простая комбинация различных линтеров, написанных на bash, чтобы помочь проверить ваш исходный код.”
Также в приведенном фрагменте кода упоминается GITHUB_TOKEN, поэтому мне было интересно узнать, зачем и для чего это нужно.
“ПРИМЕЧАНИЕ: Если вы передадите переменную окружения GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} в вашем рабочем процессе, то GitHub Super-Linter будет отмечать статус каждого отдельного запуска линтера в разделе “Проверки” запроса на выгрузку. Без этого вы будете видеть только общий статус всего прогона. Не нужно устанавливать GitHub Secret, так как он автоматически устанавливается GitHub, его нужно только передать в действие.”.
Выделенный жирным текст важно отметить на данном этапе. Мы используем его, но нам не нужно устанавливать какую-либо переменную окружения в нашем репозитории.
Для тестирования мы будем использовать наш репозиторий, который мы использовали в нашей демонстрации Jenkins.Jenkins-HelloWorld.
Вот наш репозиторий в том виде, в котором мы оставили его в сессии Jenkins.
Для того, чтобы воспользоваться преимуществами, мы должны использовать вкладку Actions выше, чтобы выбрать из рынка, о котором я расскажу в ближайшее время, или мы можем создать наши собственные файлы, используя наш код супер-лайнера выше, чтобы создать свой собственный, вы должны создать новый файл в вашем репозитории именно в этом месте. .github/workflows/workflow_name, очевидно, убедившись, что имя workflow_name - это что-то полезное для вас, узнаваемое. Здесь мы можем иметь множество различных рабочих процессов, выполняющих различные задания и задачи в нашем репозитории.
Мы создадим .github/workflows/super-linter.yml.
Затем мы можем вставить наш код и зафиксировать его в нашем репозитории, если мы перейдем на вкладку Actions, то увидим наш рабочий процесс Super-Linter в списке, как показано ниже,
Мы определили в нашем коде, что этот рабочий процесс будет запускаться, когда мы будем перемещать что-либо в наш репозиторий, поэтому при перемещении файла super-linter.yml в наш репозиторий мы запустили рабочий процесс.
Как вы можете видеть из вышеприведенного, у нас есть некоторые ошибки, скорее всего, из-за моих способностей к взлому и кодированию.
Хотя на самом деле это был не мой код, по крайней мере пока, запустив его и получив ошибку, я обнаружил вот это issue
Дубль #2 Я изменил версию Super-Linter с версии 3 на 4 и запустил задачу снова.
Как и ожидалось, мой хакерский кодинг вызвал некоторые проблемы, и вы можете увидеть их здесь, в рабочем процессе.
Я хотел показать, как теперь выглядит наш репозиторий, когда что-то в рабочем процессе не сработало или сообщило об ошибке.
Теперь, если мы решим проблему с моим кодом и внесем изменения, наш рабочий процесс снова запустится (как видно из изображения, потребовалось некоторое время, чтобы устранить наши “ошибки”). Удаление файла, вероятно, не рекомендуется, но это очень быстрый способ показать, что проблема решена.
Если вы нажмете кнопку “Новый рабочий процесс”, выделенную выше, это откроет вам дверь к огромному количеству действий. Вы, наверное, заметили, что мы не хотим изобретать колесо, мы хотим стоять на плечах гигантов и делиться нашим кодом, автоматизацией и навыками, чтобы сделать нашу жизнь проще.
О, я не показал вам зеленую галочку на репозитории, когда наш рабочий процесс был успешным.
Я думаю, что на этом основы GitHub Actions исчерпаны, но если вы похожи на меня, то вы наверняка видите, как еще можно использовать GitHub Actions для автоматизации множества задач.
Далее мы рассмотрим другую область CD, мы рассмотрим ArgoCD для развертывания наших приложений в наших средах.