GitHub Actions: проверка каждого изменения

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

Где мы находимся

Полётное повторение. В прошлом уроке была опора commit → fast checks → build once → verify → deliver → deploy deliberately. Не подглядывая, назовите её четыре звена и только затем сравните с записью.

Результат урока

Переносим локальные проверки в workflow, фиксируем permissions и используем cache без хранения секретов. Не переходите дальше, пока не можете объяснить, что проверяет каждая команда и какой отказ она обнаруживает.

Сначала знакомый образ

Автоматическая мойка начинает работу, когда датчик видит машину, затем выполняет программу на конкретном посту. GitHub Actions похож: событие запускает workflow, job получает чистый runner, а steps по порядку выполняют команды и оставляют результат.

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

Опорный сигнал урока

event → workflow → job → runner → steps → evidence

Прочитайте цепочку слева направо. Она отвечает не на вопрос «какую команду запомнить», а на вопрос «почему следующий шаг следует из предыдущего».

Новые слова простыми словами

• Workflow — YAML-файл с триггерами, полномочиями и заданиями автоматизации.
• Job — Набор шагов, выполняемый на одном runner.
• Runner — Временная машина или агент, выполняющий job.
• Permissions — Минимальные права временного токена workflow.

Разбираем без спешки

Workflow — исполняемый контракт репозитория. Триггер определяет момент, permissions — полномочия токена, job — чистую машину, steps — доказательства. Действия стороннего автора тоже являются кодом; фиксируйте доверенную версию и сокращайте права.

Сейчас не нужно запоминать формулировку дословно. Найдите в ней причинную связь и привяжите её к опорному сигналу выше.

Сначала предскажите результат

До запуска ответьте на бумаге: что должно измениться, что должно остаться прежним и какой вывод команды подтвердит ваш прогноз? Даже неверный прогноз полезен, если после опыта вы можете объяснить расхождение.

Опыт маленькими шагами

Выполните команды из корня course/cloud-devops-lab. Команды рассчитаны на учебную среду. Перед командой, меняющей сервер или данные, прочитайте её целиком и проверьте текущий каталог. Запускайте блок по одной смысловой группе. После каждой остановитесь и сопоставьте результат со своим прогнозом.

cp workflow.example.yml /tmp/cloudlab-workflow.yml
sed -n '1,220p' /tmp/cloudlab-workflow.yml
grep -n 'permissions:[|]go test[|]build-push-action' /tmp/cloudlab-workflow.yml

Эталонные файлы проекта.

Что именно делает этот опыт

Сначала прочитайте workflow как рассказ: когда начинается, на какой машине, с какими правами, какие доказательства создаёт. Затем сравните команды с локальным preflight, чтобы автоматизация не была тайным вторым способом сборки.

Что должно получиться

• Workflow имеет явные permissions.
• Команда завершается предсказуемым кодом.
• Результат можно повторить на чистой среде.

Соберите целое по опорной схеме

Проведите пальцем или карандашом по четырём блокам и расскажите весь урок одним связным объяснением.

Воспроизведите без подсказки

1. Закройте схему и нарисуйте четыре блока по памяти.
2. Объясните каждый переход словами «потому что».
3. Дайте определение одному новому термину, не повторяя текст дословно.
4. Назовите один сигнал, который доказывает результат.

Найдите и исправьте ошибку

Ошибка: «Action из Marketplace безопасен, потому что он популярен». Исправление: сторонний action выполняет код; проверяйте источник, фиксируйте версию и сокращайте permissions.

Задание

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

Обязательное. Напишите shell-команды шага CI, которые переходят в каталог проекта, запускают go test ./... и отклоняют неотформатированные Go-файлы. Отправьте только команды или скрипт POSIX sh без реальных ключей и токенов.

Критерии готовности

• Вы понимаете каждую запускаемую строку.
• Повторный запуск даёт ожидаемый результат или безопасно объяснённое отличие.
• В выводе нет настоящих ключей, токенов и паролей.
• Вы можете показать факт, который подтверждает успех.

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

По желанию. Запишите один возможный отказ и сигнал, по которому вы его заметите.

Открытая перспектива

Следующий урок добавит новую опору: Сборка и публикация одного проверенного образа.

Оглавление курса