GitHub Actions став незамінним інструментом для автоматизації CI/CD пайплайнів. Однією з найпоширеніших вимог у CI/CD робочих процесах є можливість запускати один робочий процес після іншого, забезпечуючи безперервну послідовність кроків у процесі розгортання. У цій статті ми розглянемо практичну реалізацію цього випадку використання та розберемо, як запустити другий робочий процес тільки після успішного завершення першого.
Сценарій
Уявіть, що у вас є два робочих процеси:
- Створення та завантаження образу в ECR — цей робочий процес створює Docker-образ і завантажує його в AWS Elastic Container Registry (ECR).
- Розгортання на сервері — цей робочий процес розгортає Docker-образ на вашому сервері.
Метою є забезпечити, щоб другий робочий процес (Розгортання на сервері) запускався лише після того, як перший робочий процес (Створення та завантаження образу в ECR) буде успішно завершено. Давайте розглянемо, як це налаштувати.
Робочий процес 1: Створення та завантаження образу в ECR
Цей робочий процес будує та завантажує Docker-образ в ECR, коли зміни надходять у гілку develop або при ручному запуску.
# File: .github/workflows/build.yml
name: Build and Push Image to ECR
on:
push:
branches:
- develop
workflow_dispatch:
jobs:
build:
name: Build and Push
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Log in to AWS ECR
id: login-ecr
uses: aws-actions/amazon-ecr-login@v1
- name: Build and Push Docker Image
run: |
docker build -t : .
docker tag : .dkr.ecr..amazonaws.com/:
docker push .dkr.ecr..amazonaws.com/:
Робочий процес 2: Розгортання на сервері
Цей робочий процес налаштовано таким чином, щоб він запускався після завершення першого робочого процесу. Однак ми хочемо, щоб він виконувався лише у випадку успішного завершення першого процесу.
# File: .github/workflows/deploy.yml
name: Deploy to Server
on:
workflow_dispatch:
workflow_run:
workflows: ["Build and Push Image to ECR"] #Це назва робочого процесу
types:
- completed
jobs:
deploy:
name: Deploy to Server
runs-on: self-hosted
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
- name: Deploy Application
run: |
echo "Deploying application to server..."
# Додайте тут свій скрипт для розгортання
Основні моменти
- workflow_run:
- Подія
workflow_runвикористовується у файліdeploy.yml, щоб вказати, що цей робочий процес має бути запущений після завершення робочого процесу "Build and Push Image to ECR". - Умова if
- Умова
if: ${{ github.event.workflow_run.conclusion == 'success' }}забезпечує, що робочий процес розгортання запускається лише в тому випадку, якщо попередній процес завершився зі статусомsuccess. - Підтримка ручного запуску
- Обидва робочі процеси містять
workflow_dispatch, що дозволяє запускати їх вручну для додаткової гнучкості під час тестування чи обслуговування.
Загальні проблеми та рішення
- Запуск після невдалих робочих процесів: За замовчуванням подія
workflow_runзапускається кожного разу, коли вказаний робочий процес завершується, незалежно від його статусу. Для того, щоб уникнути розгортання після невдалого створення, критично важливо використовувати умовуif. - Налагодження тригерів робочих процесів: Використовуйте логи Actions, щоб переконатися, що робочі процеси правильно з'єднані та їх тригери працюють як очікується.
Висновок
З цією конфігурацією ви можете створити надійний CI/CD пайплайн, де робочі процеси з'єднані безперервно, а дії виконуються лише після успішного завершення попередніх етапів. Такий підхід забезпечує більшу надійність і запобігає непотрібним розгортанням у разі помилок на етапі створення.
GitHub Actions пропонує неймовірну гнучкість і потужність, а поєднуючи workflow_run з умовними виразами, ви можете будувати робочі процеси, що точно відповідають вашим потребам.
Спробуйте це і поділіться своїм досвідом у коментарях нижче!
Будь ласка, розгляньте можливість підтримати мене:
- Поставити 50 оплесків за цю статтю
- Залишити коментар з вашими думками
- Підкреслити вашу улюблену частину цієї серії
Перекладено з: Chaining Workflows in GitHub Actions: Triggering One Workflow After Another