Какие операции можно совершать с Job.build в GitLab CI

Операции с Job.build в GitLab CI

В контексте GitLab CI/CD, Job.build не является прямым объектом или методом, доступным в скриптах .gitlab-ci.yml. Это скорее концепция, относящаяся к информации о выполняемом задании (Job) в рамках пайплайна. Однако, через переменные окружения, API и определенные директивы, мы можем взаимодействовать с параметрами и данными текущего задания, что по сути является операциями с "строением" (build) задания.

Основные операции, связанные с Job в GitLab CI

1. Получение информации о текущем задании через переменные окружения

    GitLab предоставляет набор предопределенных **переменных окружения** для каждого задания, которые содержат метаданные о `build`. Их можно использовать в скриптах.

```yaml
# .gitlab-ci.yml
job_example:
  script:
    - echo "Job ID: $CI_JOB_ID"
    - echo "Job Name: $CI_JOB_NAME"
    - echo "Pipeline ID: $CI_PIPELINE_ID"
    - echo "Project URL: $CI_PROJECT_URL"
```

    Ключевые переменные:
    *   **`CI_JOB_ID`** – уникальный идентификатор задания.
    *   **`CI_JOB_NAME`** – имя задания, как указано в `.gitlab-ci.yml`.
    *   **`CI_JOB_STAGE`** – этап пайплайна, в котором выполняется задание.
    *   **`CI_COMMIT_BRANCH`**, **`CI_COMMIT_TAG`** – информация о ветке или теге, для которых запущен пайплайн.

1. Взаимодействие с другими заданиями и пайплайнами

    Можно управлять зависимыми заданиями или даже запускать новые пайплайны.

    *   Использование **`needs`** для создания графа зависимостей между заданиями, позволяя заданиям начинаться раньше, не дожидаясь завершения всей стадии.

```yaml
build:
  stage: build
  script: echo "Building..."

test:
  stage: test
  script: echo "Testing..."
  needs: ["build"] # Задание test запустится сразу после завершения build, независимо от стадии.
```

    *   **Триггеры пайплайнов (`trigger`)** позволяют одному заданию запустить другой пайплайн (в том же или другом проекте), что похоже на создание нового "строения".

```yaml
trigger_downstream:
  stage: deploy
  trigger:
    project: my-group/my-downstream-project
    branch: main
```

3. Динамическое управление заданиями через API GitLab

    Используя **GitLab API**, можно совершать операции над заданиями из скриптов внутри CI/CD. Для этого часто используется переменная **`CI_JOB_TOKEN`** (специальный токен с ограниченными правами для текущего задания).

    *Пример скрипта для повторного запуска (retry) текущего задания через API:*

```bash
# script в .gitlab-ci.yml
# Повторный запуск текущего задания (например, при определенных условиях)
if [[ "$CONDITION" == "retry" ]]; then
  curl --request POST --header "JOB_TOKEN: $CI_JOB_TOKEN" \
    "https://gitlab.example.com/api/v4/projects/$CI_PROJECT_ID/jobs/$CI_JOB_ID/retry"
fi
```

    Другие возможные операции через API:
    *   Получение детальной информации о задании (`GET /projects/:id/jobs/:job_id`).
    *   Отмена задания (`POST /projects/:id/jobs/:job_id/cancel`).
    *   Удаление артефактов задания (`DELETE /projects/:id/jobs/:job_id/artifacts`).

1. Настройка и контроль выполнения задания через директивы .gitlab-ci.yml

    Само "строение" задания определяется множеством директив в конфигурационном файле.

    *   **`rules`** или **`if`** – условное выполнение задания на основе переменных (например, только для определенных веток).

```yaml
deploy_production:
  stage: deploy
  script: echo "Deploying to production..."
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
```

    *   **`parallel`** – запуск нескольких экземпляров одного задания для распределенной обработки (например, параллельное тестирование).

```yaml
run_tests:
  stage: test
  script: ./run_tests.sh
  parallel: 5 # Задание будет запущено в 5 параллельных экземплярах.
```

    *   **`retry`** – автоматическая попытка повторного запуска задания при неудаче.

```yaml
unstable_job:
  stage: test
  script: ./flakey_script.sh
  retry:
    max:-BOLD_START-2-BOLD_END # Максимум 2 попытки ретрая.
    when: runner_system_failure # Указываем условие для ретрая.
```

Итог

Прямых операций с объектом Job.build как в некоторых других CI системах в GitLab CI нет. Однако вся мощь управления заданиями реализована через:

• Предопределенные переменные для получения контекста.
• Директивы конфигурационного файла (needs, rules, parallel, retry, trigger) для управления логикой выполнения.
• GitLab API (с использованием CI_JOB_TOKEN) для программного взаимодействия с заданиями во время их выполнения или после.

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