Какво се случва след като GitLab изтегли кода?

След като GitLab изтегли кода на репозитория в работната директория, започва изпълнението на CI/CD pipeline, определена във файла .gitlab-ci.yml.

1. Анализ на .gitlab-ci.yml: GitLab Runner (или самият GitLab, ако се използва вграден CI) чете конфигурацията от .gitlab-ci.yml. Този файл описва етапите (stages) и задачите (jobs) на pipeline.
2. Инициализация на Runner: Назначава се наличен GitLab Runner за изпълнение на pipeline. Runner получава информация за репозитория, commit, клон и конфигурация на .gitlab-ci.yml.
3. Създаване на среда за изпълнение: Runner подготвя среда за изпълнение на задачите. Това може да бъде:
   • Виртуална машина
   • Контейнер (Docker, Kubernetes)
   • Отделен сървър
   • Shell
4. Изпълнение на етапите (stages): Pipeline се изпълнява последователно според определените етапи в .gitlab-ci.yml. Задачите в един етап могат да се изпълняват паралелно.
5. Изпълнение на задачите (jobs): Във всеки етап се изпълняват конфигурираните задачи. Задачата включва:
   • Определяне на образ или изпълнител (executor), ако не е зададено на ниво pipeline или секция variables.
   • Клониране на репозитория (вече е направено от GitLab, но Runner може да изпълни git fetch или git checkout за желаното състояние).
   • Възстановяване на кеша (ако е настроен) за ускоряване на създаването (например, зареждане на зависимости).
   • Изпълнение на скриптове (script): Това е основното съдържание на задачата, където се изпълняват команди за създаване, тестване, анализ или разгръщане.
   • Зареждане на артефакти (ако е конфигурирано): Резултатите от задачата (например, компилирани бинарни файлове, отчети) се запазват за по-нататъшна употреба или качване.
   • Запазване на кеша (ако е настроен) за ускоряване на бъдещи стартирания.
6. Отчитане на статус: Runner изпраща статуса на изпълнение на всяка задача (успех, грешка, анулиране) обратно към GitLab. Потребителят вижда напредъка и резултатите на страницата на pipeline.
7. Преминаване към следващ етап: Ако всички задачи в текущия етап са успешно завършили (или е настроено allow_failure), започва следващият етап. Ако задача завърши с грешка и allow_failure не е зададен, цялата pipeline се прекъсва.
8. Завършване на pipeline: След изпълнение на всички етапи (или при грешка) pipeline се приключва. Резултатите и артефактите са достъпни чрез уеб интерфейса на GitLab.

Примерна структура на .gitlab-ci.yml:

// Определяне на етапите на изпълнение на pipeline
stages:
  - build
  - test
  - deploy

// Задача за изграждане в етап build
build_job:
  stage: build
  image: docker:latest // Използване на Docker образ
  script:
    - echo "Изграждане на приложението..."
    - docker build -t myapp:$CI_COMMIT_SHORT_SHA . // Изграждане на Docker образ
  artifacts:
    paths:
      - myapp.tar // Запазване на артефакт за изграждане

// Задача за тестване в етап test
test_job:
  stage: test
  image: python:3.9 // Използване на Python образ
  script:
    - echo "Изпълнение на тестове..."
    - pip install -r requirements.txt
    - pytest // Изпълнение на тестове
  needs: ["build_job"] // Зависимост от успешно завършване на build_job

// Задача за разгръщане в етап deploy
deploy_job:
  stage: deploy
  image: ubuntu:latest // Използване на Ubuntu образ
  script:
    - echo "Разгръщане на приложението..."
    - echo "Тук се намира скриптът за разгръщане..." // Скрипт за разгръщане
  only: // Стартира само при комити към master или тагове
    - master
    - tags
  needs: ["test_job"] // Зависимост от успешно завършване на test_job

Така, изтеглянето на кода е само първата стъпка, след която следва сложен автоматизиран процес на изграждане, тестване и разгръщане, базиран на конфигурацията .gitlab-ci.yml.