Skip to main content

Рекомендуемый порядок расположения блоков внутри job в .gitlab-ci.yml?

В GitLab CI/CD есть рекомендованный порядок, который улучшает читаемость и поддержку pipeline.

📌 Стандартный порядок блоков внутри job

job_name:
  extends: .some_template  # 1️⃣ Наследование (если есть)
  stage: build             # 2️⃣ Определение этапа
  tags:                    # 3️⃣ Теги для раннера (если нужны)
    - docker
  needs:                   # 4️⃣ Зависимости от других job'ов
    - previous_job
  variables:               # 5️⃣ Локальные переменные для job
    SOME_VAR: "value"
  before_script:           # 6️⃣ Подготовка окружения перед `script`
    - echo "Setting up environment..."
  script:                  # 7️⃣ Основной код
    - echo "Executing job..."
  after_script:            # 8️⃣ Завершающие действия (если нужны)
    - echo "Cleanup after job"
  artifacts:               # 9️⃣ Артефакты (если нужны)
    paths:
      - my_output/
    expire_in: 1 hour
  rules:                   # 🔟 Условия выполнения job
    - if: '$CI_COMMIT_BRANCH == "main"'
  allow_failure: false      # 1️⃣1️⃣ Позволять ли падение job
  retry: 2                 # 1️⃣2️⃣ Число повторных попыток
  timeout: 30m             # 1️⃣3️⃣ Лимит времени выполнения

📌 Разбор структуры

СекцияОписание
extends:Наследование от шаблонного job (если есть).
stage:Назначение job к определенному этапу.
tags:Указывает, на каких раннерах будет выполняться job.
needs:Указывает зависимости от других job (если надо запустить job только после выполнения других).
variables:Определяет переменные, видимые только внутри job.
before_script:Выполняется один раз перед script: (установка окружения, логирование, авторизация и т. д.).
script:Основной код job, выполняется после before_script:.
after_script:Выполняется после script:, даже если script: упал. Подходит для логов, очистки файлов.
artifacts:Определяет файлы, которые сохраняются после завершения job.
rules:Условия выполнения job (например, только в main, только при изменениях в src/).
allow_failure:Разрешает job завершаться с ошибкой (true → ошибки не остановят pipeline).
retry:Число повторных попыток при падении job.
timeout:Лимит времени выполнения job (например, 30m).

📌 Пример 1: Минимальная конфигурация job

Если у вас простой job, можно оставить только ключевые секции:

build_job:
  stage: build
  script:
    - echo "Building the project..."

✅ Минимально необходимый job: stage: + script:.

📌 Пример 2: Расширенная конфигурация job

Если job сложный, используем все ключевые блоки:

deploy_job:
  extends: .deploy_template
  stage: deploy
  tags:
    - production-runner
  needs:
    - build_job
  variables:
    DEPLOY_ENV: "production"
  before_script:
    - echo "Подготовка к деплою..."
  script:
    - echo "Выполняем деплой..."
  after_script:
    - echo "Очистка после деплоя..."
  artifacts:
    paths:
      - deploy_logs/
    expire_in: 1 day
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  allow_failure: false
  retry: 2
  timeout: 20m

✅ Этот job должен выполниться ТОЛЬКО в main.
✅ Если job упадет, он попробует перезапуститься дважды (retry: 2).
✅ before_script: подготавливает окружение, а after_script: выполняет очистку.

📌 Итог

🚀 Оптимальный порядок блоков в job:

1️⃣ extends: (если используется)
2️⃣ stage:
3️⃣ tags: (если есть)
4️⃣ needs: (если job зависит от других job'ов)
5️⃣ variables: (локальные переменные)
6️⃣ before_script: (подготовка окружения)
7️⃣ script: (основная логика job)
8️⃣ after_script: (очистка, логи)
9️⃣ artifacts: (если нужны)
🔟 rules: (условия выполнения)
1️⃣1️⃣ allow_failure: (можно ли игнорировать ошибки)
1️⃣2️⃣ retry: (количество повторных попыток)
1️⃣3️⃣ timeout: (ограничение времени выполнения)


Back to top