Якщо у вас є члени команди, які не повинні мати доступу до GitHub, але працюють залежно від нього, інтеграція сповіщень — найкраще, що ви можете додати.
Також ця стаття буде корисна тим, хто хоче автоматизувати звітність про виконані дії на GitHub. Або хочете дізнатися, як використовувати вихідні дані для багаторазових робочих процесів.
Немає значення, яку хмару ви використовуєте. У цьому методі ми все ще можемо запустити сам робочий процес або викликати його з іншого робочого процесу.
Крок 1. Налаштуйте багаторазові робочі процеси
По-перше, давайте додамо багаторазові (викликані) робочі процеси
- Створення файлів:
2. Тепер давайте налаштуємо робочі процеси, щоб зробити їх повторно використаними від root:
aks_ci, web_app_docker_ci_1, web_app_docker_ci_2 матиме однакові конфігурації для надсилання кодів статусу завдання та виклику іншими робочими процесами. Тому ви можете записати їх аналогічно.
Від CI нам потрібні кілька завдань (збірка та розгортання)..
Усі ці робочі процеси повинні мати workflow_call і результати
Майте на увазі, що workflow_call не має нічого спільного з workflow_dispatch. Це абсолютно різні конфігурації.
У конфігурації workflow_call ми оголосимо, що будемо виводити змінні з іменами 'build_status' і 'deploy_status' і звідки їх отримати..
3. Тоді нам потрібно отримати сам вихід із кроку збірки:
Ми не можемо не згадати, що «Статус етапу збірки» має бути після кроків збірки (між рядками 46 і 48)..
Зауважте, що тут ми використовуємо наші ідентифікатори кроків. Використовуючи цей ідентифікатор, ми можемо ідентифікувати саме цей вихід.
Те саме для роботи з розгортання
Код розгортання має бути між рядками 79 і 81.
4. cypress_test_ci може бути як будь-який робочий процес, який не потребує отримання статусу кожного завдання. Це означає, що ми можемо отримати статус робочого процесу в цілому.
Крок 2 - Налаштуйте кореневий робочий процес
Нарешті, ми можемо додати кореневий робочий процес.
- Створіть файл root_ci:
2. Додайте виклики до цього робочого процесу, щоб використовувати багаторазові конфігурації, які ми створили.
Крок 3. Конфігурації для будь-яких типів сповіщень
Щойно ми додамо багаторазові та кореневі робочі процеси, вихідні змінні стану для багатозадачності, ми можемо почати використовувати його.
Давайте додамо завдання сповіщення до кореневого робочого процесу: (почніть з рядка 28)
Тут ми додали конфігурацію для запуску в будь-якому випадку, навіть якщо попередні завдання виконано успішно або виконано з помилками. Сповіщення використовуватимуться, коли всі завдання будуть виконані з будь-яким статусом
Загалом сповіщення можна розділити на 4 частини:
- Успішно закінчено
- Помилка збірки – повна помилка робочого процесу
- Помилка розгортання – збірка була успішною, але розгортання не вдалося.
- Тест успішно завершено.
Успішно закінчено
Якщо розгортання та тестування завершено успішно, сповіщення буде успішним.
Робочий процес повністю вийшов з ладу
Якщо збірку буде завершено невдало, сповіщення не буде надіслано.
Збірка пройшла успішно, але розгортання не вдалося
Якщо розгортання буде завершено невдало, сповіщення не буде надіслано.
Тест завершився успішно, але збірка та розгортання не вдалися
Якщо збірка і розгортання завершилися невдало, але тестування пройшло успішно, з'явиться повідомлення про успішне тестування з невдалим розгортанням.
Висновок
Багаторазові робочі процеси та системи сповіщень - це дійсно гнучке та потужне доповнення до автоматизації, яке може допомогти вашій команді прискорити CI/CD та спростити відстеження прогресу.
Посилання
- Calling reusable workflows - [https://docs.github.com/ru/actions/sharing-automations/reusing-workflows#calling-a-reusable-workflow]
- Creating reusable workflows - [https://docs.github.com/ru/actions/sharing-automations/reusing-workflows#creating-a-reusable-workflow]
- Outputs - [https://docs.github.com/ru/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs#example-defining-outputs-for-a-job]
- Conditionals - [https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/using-conditions-to-control-job-execution]
Dependences - [https://docs.github.com/ru/actions/writing-workflows/workflow-syntax-for-github-actions#example-requiring-successful-dependent-jobs]
Денис Тужилін | DevOps & Solution Architecture | CI/CD | GitHub actions