leafleafleafDocy banner shape 01Docy banner shape 02Man illustrationFlower illustration

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

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

Данная статья представляет собой шпаргалку по созданию 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

Существуют две специальные стадии, которые не нужно предварительно указывать в разделе 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
...
				
			

Tags

Параметр tags в GitLab CI используется для назначения задач конкретным runner’ам, которые соответствуют заданным тегам. Теги помогают контролировать, на каком runner’е будет выполняться задача, особенно когда у вас есть несколько runner’ов с разными характеристиками или установленным ПО:

				
					NAME-JOB:
  tags:
    - docker
    - linux
  script:
    - echo "Running a task"
...
				
			

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
				
			

 

Источники:

Тык Тык 

Leave a Comment

Поделиться этой страницей

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

Или скопируйте ссылку

СОДЕРЖИМОЕ