Шпаргалка по написанию Pipelines

Время чтения: 3 мин. 412 просмотров

Данная статья представляет собой шпаргалку по созданию GitLab-пайплайнов. В ней собраны шаблоны и конструкции, которые можно использовать в качестве основы для разработки собственных CI/CD процессов.

Шаблоны

Шаблон пайплайна:

				
					variables:
    GLOBAL_VAR: "Global variables"
    
stages:
    - build
    - test
    - delivery
    - deploy

build-job:
    stage: build
    image: ubuntu:22.04
    tags:
        - build
	variables:
	    - LOCAL_VAR: "Local variables"
    script:
        - mkdir build
        - echo ${GLOBAL_VAR} >> build/artifact.txt
		- echo ${LOCAL_VAR} >> build/artifact.txt
    artifacts:
        paths:
            - build/
        expire_in: 1h

test-job:
    stage: test
    tags:
        - test
    script:
        - cat build/artifact.txt
		
delivery-job:
    stage: delivery
    tags:
        - test
    only:
        - main
	when: manual
    before_script:
        - echo "Before script"
    script:
        - echo "Script"
    after_script:
        - echo "After script"

deploy-job:
    stage: deploy
    tags:
        - prod
    only:
        - main
    needs:
        - job: delivery-job
    script:
        - echo "Script"

Переменные

Переменные объявляются с использованием директивы variables.

Их можно задать глобально для всех задач:

				
					variables:
  GLOBAL_VAR: "Global variables"
...

Или локально для конкретного задания:

				
					JOB:
  ...
  variables:
        - LOCAL_VAR: "Local variables"
...

Стадии

В разделе stages определяются этапы выполнения пайплайна в GitLab. В данном случае перечислены следующие стадии:

build – этап сборки, где происходит компиляция или сборка проекта.
test – этап тестирования, на котором запускаются тесты для проверки качества кода.
delivery – этап доставки, на котором артефакты или релизы подготавливаются для последующей отправки в целевую среду.
deploy – этап развертывания, где проект деплоится в целевую среду (например, на сервер или в облако).

				
					stages:
  - build
  - test
  - delivery
  - deploy
...

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

Существуют две специальные стадии, которые не нужно предварительно указывать в разделе stages:

.pre – эта стадия запускается перед выполнением всех основных заданий пайплайна;
.post – эта стадия выполняется после завершения всех основных заданий пайплайна.

В этом примере перед началом выполнения всех задач сборки определяем переменную с версией, считав ее из файла, и передаем ее как системную переменную VERSION через артефакт:

				
					stages:
  - build
  - test

getVersion:
  stage: .pre
  script:
    - VERSION=$(cat VERSION_FILE")
    - echo "VERSION=${VERSION}" > variables.env
  artifacts:
    reports:
      dotenv: variables.env

Задачи

Задачи в GitLab CI представляют собой отдельные шаги, которые выполняются на различных этапах пайплайна. Каждая задача может включать в себя различные команды, скрипты и параметры:

				
					NAME-JOB:
  stage: ...
  image: ...
  tags:
    ...
  only:
    ...
  needs:
    ...
  when: ...
  variables:
    ...
  before_script:
    ...
  script:
    ...
  after_script:
    ...
  artifacts:
    ...
...

Stage

Параметр stage в GitLab CI используется для указания этапа пайплайна, на котором должна быть выполнена конкретная задача:

				
					stages:
  - build
  - test
  - delivery
  - deploy

NAME-JOB:
  stage: build
	
NAME-JOB:
  stage: test

Image

Параметр image в GitLab CI используется для указания Docker-образа, который будет использован в качестве окружения для выполнения задач. Этот параметр особенно полезен, когда нужно обеспечить консистентность окружения для выполнения команд, независимо от того, на каком runner’е запускается пайплайн:

				
					NAME-JOB:
  image: curlimages/curl:latest
  script:
    - curl -o AUTH-X3.pem https://letsencrypt.org/certs/letsencryptauthorityx3.pem.txt
...

Only

Параметр only в GitLab CI используется для указания условий, при которых задача должна выполняться. Этот параметр позволяет контролировать, когда задача будет запускаться, основываясь на ветках, тегах, событиях и других условиях:

				
					NAME-JOB:
  only:
    - main
  script:
    - echo "Deploying the project"
...

Needs

Параметр needs в GitLab CI позволяет задавать условия для выполнения задач, основываясь на наличии определенных артефактов или успешном выполнении других заданий. Этот параметр помогает управлять последовательностью выполнения задач и их зависимостями.

Пример, в котором задача deploy-job выполняется только после успешного завершения предыдущей задачи delivery-job:

				
					delivery-job:
  script:
    - echo "Running a task"

deploy-job:
  needs:
    - job: delivery-job
  script:
    - echo "Deploying the project"

When

Параметр when в GitLab CI используется для определения условий, при которых задача должна быть выполнена. Этот параметр управляет временем выполнения задачи в зависимости от результатов выполнения предыдущих задач и других условий.

Возможные значения:

on_success (по умолчанию) – задача выполняется, если все предыдущие задачи завершились успешно;
on_failure – задача выполняется только в случае ошибки в одной из предыдущих задач, можно использовать для отправки уведомлений о сбоях:

				
					NAME-JOB:
  when: on_failure
  script:
    - echo "Deploying the project"
...

always – задача выполняется независимо от результатов предыдущих задач, можно использовать для очистки ресурсов:

				
					NAME-JOB:
  when: always
  script:
    - echo "Deploying the project"
...

manual – задача требует ручного запуска через интерфейс GitLab:

				
					NAME-JOB:
  when: manual
  script:
    - echo "Deploying the project"
...

never – задача никогда не выполняется, даже если другие задачи завершены успешно:

				
					NAME-JOB:
  when: never
  script:
    - echo "Deploying the project"
...

delayed – задача выполняется с задержкой, указанной в параметре start_in. Это позволяет отложить выполнение задачи на заданное время после завершения предыдущих:

				
					NAME-JOB:
  when: delayed
  start_in: 30 minutes
  script:
    - echo "Deploying the project"
...

Before_script

Параметр before_script в GitLab CI используется для выполнения команд перед основной частью задачи. Это позволяет выполнить общие настройки или подготовку, которые необходимы для выполнения скрипта задачи:

				
					NAME-JOB:
  before_script:
    - echo "Run before_script"
  script:
    - echo "Deploying the project"
...

Script

Параметр script в GitLab CI используется для указания команд, которые должны быть выполнены в рамках задачи:

				
					NAME-JOB:
  script:
    - echo "Running a task"
    - echo "Deploying the project"
...

After_script

Параметр after_script в GitLab CI используется для указания команд, которые должны быть выполнены после основной части задачи. Эти команды выполняются после выполнения всех команд, указанных в параметре script, независимо от того, завершилась задача успешно или с ошибкой. Это позволяет выполнять завершающие действия, такие как очистка ресурсов, отправка отчетов или запись логов:

				
					NAME-JOB:
  script:
    - echo "Deploying the project"
  after_script:
    - echo "Cleaning up after the job"
...

Artifacts

Параметр artifacts в GitLab CI используется для сохранения файлов и каталогов, созданных в ходе выполнения задачи, и последующего использования этих артефактов в других задачах или этапах пайплайна.

Параметры:

paths – список файлов и директорий, которые должны быть сохранены как артефакты;
exclude – список файлов и директорий, которые должны быть исключены из артефактов, даже если они указаны в paths;
expire_in – время, в течение которого артефакты должны храниться (например, 1 week, 3 days, 1 h). После этого времени они будут автоматически удалены.

Пример:

				
					NAME-1-JOB:
  artifacts:
    paths:
      - ${PKG_NAME}.deb
      - ${PKG_NAME}.rpm
      - *.txt
      - configs/
	exclude:
      - ./.git/**/*
	  
NAME-2-JOB:
  script:
    - cat *.txt
    - yum -y localinstall ${PKG_NAME}.rpm
    - apt -y install ./${PKG_NAME}.deb

Trigger

Параметр trigger в GitLab CI используется для запуска пайплайна другого проекта из текущего.

				
					NAME-JOB:
  stage: deploy
  variables:
    TEXT: "hello world"
  trigger:
    project: my-group/another-project
    branch: main
    strategy: depend
...

Параметры:

project – проект, в котором нужно запустить downstream пайплайн;
branch – ветка в downstream проекте, на которую будет запускаться пайплайн;
strategy – способ ожидания downstream пайплайн:
- depend — дожидается завершения downstream пайплайн и наследует его статус (не должно быть заданий с ручным запуском);
- (без параметра) — запускает downstream пайплайн и сразу завершает работу upstream пайплайн с успешным статус.

Источники:

Тык Тык

WinHexs Blog