Что реализуют на этапе выборки CI/CD?

Что реализуют на этапе выборки (Fetch/Checkout) в CI/CD

Этап выборки (Fetch, Checkout или Get Sources) — это фундаментальный начальный этап любого конвейера CI/CD. Его основная цель — получение актуального исходного кода приложения из системы контроля версий (VCS) в изолированное рабочее пространство (workspace) на агенте или сервере сборки. Это отправная точка, от которой зависит успех всех последующих шагов.

Ключевые задачи, реализуемые на этапе выборки:

1. Извлечение указанной ревизии кода

    *   Конвейер определяет, *какую именно версию кода* необходимо обработать. Обычно это **ветка, тег или конкретный коммит**, который инициировал запуск пайплайна (например, push в ветку `main` или создание pull/merge request).
    *   Пример в GitLab CI:

    ```yaml
    job:
      script:
        - echo "Код из ветки $CI_COMMIT_BRANCH, коммит $CI_COMMIT_SHA был успешно получен."
    ```

2. Обеспечение изоляции и воспроизводимости

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

1. Передача контекста и метаданных

    *   Современные CI/CD-системы (GitHub Actions, GitLab CI, Jenkins с плагинами) автоматически передают в окружение переменные, содержащие **критическую информацию о событии**:
        *   `GIT_COMMIT` / `CI_COMMIT_SHA` — хеш коммита.
        *   `GIT_BRANCH` / `CI_COMMIT_REF_NAME` — имя ветки или тега.
        *   `GIT_AUTHOR` — автор изменений.
        *   Ссылка на пулл-реквест, сообщение коммита и т.д.
    *   Этот контекст используется для логирования, нотификаций, условного выполнения шагов и артефактов именования.

1. Кэширование репозитория для ускорения

    *   Для оптимизации, агенты часто **кэшируют локальную копию репозитория**. При новом запуске система выполняет не полный клон, а `fetch` и `checkout` необходимой ревизии, что значительно быстрее.
    *   Пример настройки кэша в GitHub Actions:

    ```yaml
    - name: Cache Git repository
      uses: actions/cache@v3
      with:
        path: |
          ~/.git
          .git
        key: ${{ runner.os }}-git-${{ hashFiles('.git/HEAD') }}
    ```

5. Обработка субмодулей и вложенных репозиториев

    *   Если проект использует Git субмодули или аналогичные зависимости, этап выборки должен их рекурсивно инициализировать и обновить.
    *   Пример включения субмодулей в `.gitlab-ci.yml`:

    ```yaml
    variables:
      GIT_SUBMODULE_STRATEGY: recursive
    ```

6. Безопасность и контроль доступа

    *   CI/CD-система аутентифицируется в VCS (часто по **токену доступа** или SSH-ключу) для получения кода. Это критически важный момент безопасности, требующий управления секретами (secrets).
    *   Проверяются права агента на чтение репозитория.

Техническая реализация в разных системах

• Jenkins: Шаг checkout scm в декларативном пайплайне или использование узла git в скриптовом.

  pipeline {
      agent any
      stages {
          stage('Checkout') {
              steps {
                  checkout([
                      $class: 'GitSCM',
                      branches: [[name: '*/main']],
                      userRemoteConfigs: [[url: 'https://github.com/example/repo.git']]
                  ])
              }
          }
      }
  }
  

• GitHub Actions: Действие actions/checkout@v4 является стандартом де-факто.

  jobs:
    build:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
          with:
            fetch-depth: 1 # Неполная история для скорости
            submodules: 'recursive'
  

• GitLab CI: Выборка происходит автоматически перед первым шагом job, но может быть настроена через переменные или отключена.

Почему это важно?

Провал на этапе выборки означает, что весь последующий конвейер (тесты, сборка, развертывание) либо не запустится, либо будет выполняться на неверной или устаревшей версии кода. Корректная и быстрая выборка — основа воспроизводимости, предсказуемости и надежности всего процесса CI/CD. Это не просто "скачивание файлов", а создание детерминированного и аудируемого контекста для автоматизированной обработки кода.