Задания (tasks)

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

Каждое задание содержит в себе набор минимальных логических действий — кубиков. Результатом задания является выполнение всех кубиков.

По умолчанию задание начинается с клонирования репозитория.

Все задания рабочего процесса запускаются параллельно.

В заданиях и кубиках вы можете использовать переменные окружения, а также секреты.

Вы можете задать настройки конкретного задания как внутри блока workflows:tasks, так и в отдельном блоке tasks и сослаться на него из блока workflows:tasks. Общие параметры для обоих вариантов описываются одинаково, однако параметры uses и approval можно использовать только внутри workflows:tasks.

Поддерживаются следующие параметры:

• name — имя задания.

• cubes — список кубиков, которые будут выполняться в задании. Подробнее в разделе cubes.

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

  Совет

  Также вы можете задать переменные окружения внутри следующих блоков:

  • workflows — переменные будут доступны во всех кубиках всех заданий конкретного рабочего процесса.
  • cubes — переменные будут доступны в конкретном кубике.

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

  Важно

  Параметр needs можно использовать только внутри блока workflows:tasks. Не допускается использовать в отдельном блоке tasks.

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

• approval — настройки ручного подтверждения выполнения задания. Параметр можно использовать только в заданиях внутри блока workflows:tasks.

• outputs — выходные значения задания, которые можно передать зависимым заданиям. Значения задаются выражениями, которые ссылаются на выходные значения кубиков или заданий. Подробнее на странице Передача данных между заданиями CI/CD SourceCraft.

• runs_on — метки воркера, на котором будут запущены задания рабочего процесса. По умолчанию будет выставлен параметр из workflow:runs_on.

• checkout — настройки автоматического клонирования репозитория перед выполнением задания. По умолчанию будут применены настройки из workflow:checkout.

runs_on

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

• runtime-метка — тип воркера. Возможные значения:

  • compute — облачный воркер. Значение по умолчанию.
  • serverless — serverless-воркер. Примеры.
  • self-hosted — пользовательский (self-hosted) воркер.

  Важно

  В поле runs_on не может быть указано более одной runtime-метки. Если runtime-метка не указана, по умолчанию применяется compute.

• метки пользовательских воркеров.

  Примечание

  В строковых значениях метки может содержаться ограниченный набор символов: буквы латинского алфавита (a-zA-Z), а также -, . и _.

  Метка self-hosted проставляется в параметрах пользовательского воркера автоматически. Ее не надо добавлять дополнительно в поле tags файла config.yaml.

Пример задания внутри блока workflows:tasks

workflows:
  my-workflow:
    tasks:
      - name: my-task
        cubes:
    ...

Пример задания в отдельном блоке tasks

tasks:
  - name: common-task

workflows:
  my-workflow:
    tasks:
      - common-task

Пример нескольких заданий в отдельном блоке tasks

tasks:
  - name: common-task-1
  - name: common-task-2

workflows:
  my-workflow:
    tasks:
      - [common-task-1, common-task-2]

Пример комбинированного варианта указания заданий

tasks:
  - name: common-task-1
  - name: common-task-2
  - name: common-task-3

workflows:
  my-workflow:
    tasks:
      - common-task-1
      - [common-task-2, common-task-3]
      - name: my-task
        cubes:
    ...

Пример использования зависимостей

tasks:
  # Задание, которое выполняется без зависимостей.
  - name: sample-task
    cubes:
      - name: sample-cube
        script:
          - echo "Hello, World"
          - sleep 1

workflows:
  sample-workflow:
    tasks:
      # Ссылка на задание-оригинал tasks:sample-task.
      - sample-task
      - name: another-task
        # Задание another-task будет выполнено только после
        # успешного завершения задания sample-task.
        needs: [sample-task]
        script:
          - echo "Here we go again"
          - sleep 1
      - name: yet-another-task
        # Задание yet-another-task будет выполнено только после
        # успешного завершения заданий sample-task и another-task.
        needs: [sample-task, another-task]
        script:
          - echo "Goodbye, World"
          - sleep 1

approval

Если ручное подтверждение включено, после запуска CI/CD задание создается в статусе Created и помещается в очередь ожидания. Пока зависимости, заданные в параметре needs, выполняются, задание остается в этом статусе. После успешного выполнения зависимостей или при их отсутствии задание переходит в статус AwaitingApproval. С этого момента начинается отсчет времени ожидания решения.

Возможные результаты ожидания:

• Подтверждение (approve) — задание переносится в очередь выполнения и запускается в обычном режиме. В сведениях о решении сохраняются результат approved, автор и комментарий.
• Отклонение (reject) — задание получает статус Rejected и удаляется из очереди ожидания. В сведениях о решении сохраняются результат rejected, информация об авторе и комментарий. Статус Rejected распространяется на рабочий процесс и весь запуск CI/CD.
• Истечение времени ожидания (expire) — если решение не принято вовремя, задание получает статус Canceled, а в сведениях о решении сохраняется результат expired. Статус Canceled распространяется на рабочий процесс и весь запуск CI/CD.

Задание с ручным подтверждением не запускается автоматически после успешного выполнения зависимостей, а ожидает решения пользователя: подтвердить (approve) или отклонить (reject) выполнение. Такой механизм позволяет, например, проверить результат перед развертыванием в продуктовом окружении.

Поддерживаются следующие формы записи:

• approval: true — включить ручное подтверждение со временем ожидания по умолчанию — 24 часа.
• approval: false — явно отключить ручное подтверждение. Эквивалентно отсутствию параметра approval.
• approval: {} — включить ручное подтверждение с параметрами по умолчанию.
• approval: { timeout: ..., note: ..., require_comment: ... } — включить ручное подтверждение с явно заданными параметрами.

В блоке approval поддерживаются следующие параметры. Все параметры опциональны:

• timeout — максимальное время ожидания решения, например 1h или 2h. Значение по умолчанию — 24h. Время отсчитывается с момента перехода задания в статус AwaitingApproval. По истечении этого времени задание автоматически отменяется.
• note — инструкция для пользователя, который принимает решение. Задается строкой длиной до 1000 символов и отображается в интерфейсе. По умолчанию не задана.
• require_comment — требование добавить комментарий при подтверждении или отклонении задания. Задается логическим значением. Значение по умолчанию — false. Если установлено значение true, принять решение можно только с комментарием. Максимальная длина комментария — 2000 символов, не зависит от значения require_comment.

Пошаговая инструкция приведена на странице Настроить ручное подтверждение заданий CI/CD в SourceCraft.

Пример ручного подтверждения со временем ожидания по умолчанию

workflows:
  release:
    tasks:
      - name: publish
        approval: true
        cubes:
          - name: publish-cube
            script:
              - echo "publish"

Пример задания с зависимостью и ручным подтверждением

workflows:
  deploy:
    tasks:
      - name: build
        cubes:
          - name: build-cube
            script:
              - echo "build"
      - name: deploy
        needs: [build]
        approval:
          timeout: 1h
        cubes:
          - name: deploy-cube
            script:
              - echo "deploy"

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

workflows:
  deploy:
    tasks:
      - name: build
        cubes:
          - name: build-cube
            script:
              - echo "build"
      - name: deploy-prod
        needs: [build]
        approval:
          timeout: 2h
          note: "Проверьте дашборды тестового окружения"
          require_comment: true
        cubes:
          - name: deploy-cube
            script:
              - echo "deploy"

В этом примере после успешного выполнения задания build задание deploy-prod будет ожидать решения пользователя до двух часов. Для подтверждения или отклонения выполнения потребуется комментарий. Команды echo иллюстрируют порядок выполнения заданий: замените их командами сборки и развертывания вашего приложения.

Пример явного отключения ручного подтверждения

workflows:
  deploy:
    tasks:
      - name: deploy-forced
        approval: false
        cubes:
          - name: deploy-cube
            script:
              - echo "deploy"

checkout

В блоке checkout указываются настройки автоматического клонирования репозитория, в котором запускается рабочий процесс. Если блок задан как на уровне рабочего процесса, так и на уровне задания, то для задания применяются его собственные настройки.

Поддерживаются следующие параметры:

• enabled — признак автоматического клонирования репозитория перед выполнением задания. Значение по умолчанию — true. Если установлено значение false, перед стартом задания репозиторий не клонируется. В этом случае при необходимости получите содержимое репозитория самостоятельно в одном из кубиков задания.

  Примечание

  Значение параметра доступно в предопределенной переменной окружения SOURCECRAFT_CHECKOUT_ENABLED.

• fetch_depth — количество последних записей истории, которые будут загружены при клонировании репозитория. По умолчанию параметр не задан, и репозиторий клонируется на всю глубину истории.

  Совет

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

• remove_credentials — признак удаления ключа авторизации из файла .git/config после клонирования репозитория. Значение по умолчанию — false. Установите значение true, если требуется запретить дальнейшие операции с удаленным репозиторием из кубиков задания под аутентификацией CI/CD.

• retry — настройки автоматического перезапуска клонирования репозитория. Параметр задается в одном из следующих форматов:

  • Число — максимальное количество повторных попыток клонирования. Подробнее в подразделе Перезапуск по умолчанию.
  • Структура с условиями перезапуска. Подробнее в подразделе Перезапуск с условиями.

  В отличие от параметра retry кубика, настройка влияет только на перезапуск клонирования репозитория. По умолчанию автоматический перезапуск клонирования отключен.

Пример настройки клонирования репозитория на уровне задания

tasks:
  - name: ci-build
    checkout:
      retry: 2
      enabled: true
      remove_credentials: false
      fetch_depth: 10

Полезные ссылки

• Переиспользование параметров рабочих процессов и кубиков в CI/CD SourceCraft
• Передача переменных окружения от одного кубика к другому в CI/CD SourceCraft
• Передача данных между заданиями CI/CD SourceCraft
• Кубики (cubes)
• События-триггеры (on)
• Рабочие процессы (workflows)
• Непрерывная интеграция и непрерывное развертывание в SourceCraft
• Настроить CI/CD в репозитории SourceCraft
• Управлять секретами в репозитории SourceCraft
• Работа с переменными окружения в SourceCraft