CI/CD with GitHub Actions & DevOps Pipelines · Урок

Повторно используемые рабочие процессы и действия

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

«Повторно используемые рабочие процессы и действия» — бесплатный урок CI/CD with GitHub Actions & DevOps Pipelines на CoddyKit. Это урок 3 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения CI/CD with GitHub Actions & DevOps Pipelines, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс CI/CD with GitHub Actions & DevOps Pipelines содержит 4 уроков всего.

Введение в повторное использование рабочих процессов

В современной разработке программного обеспечения эффективность и согласованность особенно важны. По мере роста проектов растут и требования к автоматизации.

Повторно используемые рабочие процессы и пользовательские действия в GitHub Actions помогают не дублировать код, делая Ваши конвейеры CI/CD удобнее для сопровождения и надежнее.

Зачем повторно использовать рабочие процессы?

Представьте, что у Вас несколько приложений, которым нужны одинаковые шаги сборки, тестирования или развертывания. Копирование кода рабочего процесса приводит к следующим проблемам:

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

Повторное использование решает эти проблемы!

Определение повторно используемого рабочего процесса

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

Чтобы сделать рабочий процесс повторно используемым, используется событие workflow_call. Оно сообщает GitHub Actions, что этот рабочий процесс предназначен для вызова, а не для запуска типичными событиями, такими как push или pull_request.

Пример повторно используемого рабочего процесса

Вот простой повторно используемый рабочий процесс, имитирующий сборку. Сохраните его в .github/workflows/reusable-build.yml.

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

name: Reusable Build Component

on:
  workflow_call:
    outputs:
      build_id:
        description: "The ID of the build operation"
        value: ${{ jobs.build.outputs.build_id }}

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      build_id: ${{ steps.generate_id.outputs.id }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Generate build ID
        id: generate_id
        run: echo "id=$(date +%s)" >> "$GITHUB_OUTPUT"
      - name: Simulate build
        run: echo "Building project with ID ${{ steps.generate_id.outputs.id }}..."

Вызов повторно используемого рабочего процесса

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

Укажите путь к файлу повторно используемого рабочего процесса в Вашем репозитории или даже в другом репозитории либо к определенной версии.

Пример вызывающего рабочего процесса

Этот рабочий процесс, сохранённый в .github/workflows/main-app-ci.yml, вызывает наш рабочий процесс reusable-build.yml.

Заметьте, как он получает выходные данные build_id из вызванного рабочего процесса с помощью jobs.call-build.outputs.build_id.

name: Main App CI

on: [push]

jobs:
  call-build:
    uses: ./.github/workflows/reusable-build.yml
    outputs:
      build_id: ${{ jobs.call-build.outputs.build_id }}
  
  deploy:
    needs: call-build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy app
        run: echo "Deploying app built with ID ${{ needs.call-build.outputs.build_id }}"

Передача входных данных в повторно используемые рабочие процессы

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

Ожидаемые входные данные определяются в разделе on: workflow_call: inputs: повторно используемого рабочего процесса. Для них указываются тип, обязательность и описание. Вызывающий рабочий процесс передает эти данные с помощью ключевого слова with:.

Повторно используемый рабочий процесс с входными данными

Вот обновленный файл reusable-build.yml, принимающий входной параметр target_env. Благодаря этому одну и ту же логику сборки можно настраивать для разных сред.

name: Reusable Build Component with Input

on:
  workflow_call:
    inputs:
      target_env:
        required: true
        type: string
        description: "The target environment for the build"
    outputs:
      build_id:
        description: "The ID of the build operation"
        value: ${{ jobs.build.outputs.build_id }}

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      build_id: ${{ steps.generate_id.outputs.id }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Generate build ID
        id: generate_id
        run: echo "id=$(date +%s)" >> "$GITHUB_OUTPUT"
      - name: Simulate build for ${{ inputs.target_env }}
        run: echo "Building project for ${{ inputs.target_env }} with ID ${{ steps.generate_id.outputs.id }}..."

Пример вызова с входными данными

Теперь основной рабочий процесс CI может дважды вызвать повторно используемый компонент сборки: один раз для «тестовой среды», а другой — для «продуктивной среды», передавая разные значения target_env.

name: Main App CI with Input

on: [push]

jobs:
  call-build-staging:
    uses: ./.github/workflows/reusable-build-with-input.yml
    with:
      target_env: 'staging'
    outputs:
      build_id: ${{ jobs.call-build-staging.outputs.build_id }}
  
  call-build-prod:
    uses: ./.github/workflows/reusable-build-with-input.yml
    with:
      target_env: 'production'
    outputs:
      build_id: ${{ jobs.call-build-prod.outputs.build_id }}

Повторно используемые рабочие процессы и пользовательские действия

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

Повторно используемые рабочие процессы: координируют последовательность задач. Они определяют полную структуру рабочего процесса, например сборку, тестирование и развертывание.
Пользовательские действия: выполняют одну конкретную задачу внутри задачи, например настраивают Node.js или публикуют пакет. Это строительные блоки, расположенные *внутри* шагов задачи.

Представьте, что рабочие процессы — это рецепты, а действия — отдельные ингредиенты или шаги.

Быстрая проверка

Какие из перечисленных вариантов являются ключевыми преимуществами использования повторно используемых рабочих процессов в GitHub Actions?

Итоги: повторно используемые рабочие процессы и действия

Мы рассмотрели, как повторно используемые рабочие процессы помогают разделять конвейеры CI/CD на модули.

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

Повторное использование позволяет создавать более эффективную, единообразную и удобную в сопровождении автоматизацию во всех ваших проектах.

Часто задаваемые вопросы

Урок «Повторно используемые рабочие процессы и действия» бесплатный?

Да — полный текст урока «Повторно используемые рабочие процессы и действия» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс CI/CD with GitHub Actions & DevOps Pipelines, подпишись на CoddyKit PRO. Курс CI/CD with GitHub Actions & DevOps Pipelines содержит 4 уроков всего.

Чему я научусь в уроке «Повторно используемые рабочие процессы и действия»?

Создавайте и используйте повторно рабочие процессы и пользовательские действия, чтобы сделать конвейеры модульными и обеспечить единообразие в репозиториях. Ты практикуешь CI/CD with GitHub Actions & DevOps Pipelines с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать CI/CD with GitHub Actions & DevOps Pipelines?

Предыдущий опыт не требуется. CI/CD with GitHub Actions & DevOps Pipelines на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 3 из 4.

Сколько времени занимает урок «Повторно используемые рабочие процессы и действия»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке CI/CD with GitHub Actions & DevOps Pipelines?

Да. Каждый урок CI/CD with GitHub Actions & DevOps Pipelines включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

Матричные сборки для нескольких сред
Кэширование зависимостей для ускорения
Повторно используемые рабочие процессы и действия
Условное выполнение и зависимости заданий

← Назад к CI/CD with GitHub Actions & DevOps Pipelines