GitLab — определение и запись спецификаций заданий

Атрибут «спецификации»?

Атрибут «specs» появился в GitLab CI с версии GitLab 15.11 (как упоминалось в этом сообщении блога).

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

Когда мне следует использовать атрибут спецификации?

Чтобы проиллюстрировать одно из преимуществ использования этого атрибута, позвольте мне объяснить это на примере. Эта простая команда позволяет развернуть службу Cloud Run на основе образа Docker под названием my-image.

gcloud run deploy my-service --image my-image

Это работает, но если я хочу оптимизировать этот скрипт и использовать его для других сервисов, я могу заменить имена моего сервиса и моего изображения переменными, вот так:

gcloud run deploy $MY_SERVICE --image $MY_IMAGE

Чтобы интегрировать эту команду в задание GitLab CI, я могу просто включить ее в scriptатрибут внутри задания:

deploy-cloud-run-services:
[...]
script: 
gcloud run deploy $MY_SERVICE --image $MY_IMAGE

До выпуска GitLab 15.11 или без specs атрибут, как мне вызвать этот скрипт?

Если все задания определены в одном файле .gitlab-ci.yml, я могу добавить variables атрибут:

variables: 
  MY_SERVICE: my-service-1
  MY_IMAGE: my-image-1

deploy-cloud-run-services:
[...]
script: 
gcloud run deploy $MY_SERVICE --image $MY_IMAGE

В большинстве случаев «реальной жизни» не все ваши задания находятся в одном файле. Ну я на это надеюсь 😅. С помощью include атрибут, вы можете связать файлы, и ваши переменные будут автоматически отправлены во включенные задания.

Файл .gitlab-ci.yml:

stages:
  - deploy 

variables: 
  MY_SERVICE: my-service-2
  MY_IMAGE: my-image-2

include:
  - local: jobs-deploy.yml

задания-deploy.yml

deploy-cloud-run-services:
  stage: deploy
  script: 
    - echo $MY_SERVICE " - " $MY_IMAGE

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

Единственный способ проверить влияние на ваши конвейеры — это выполнить их. Однако, если что-то пойдет не так, вы будете проинформированы немного позже.

Вот почему specs атрибут может сэкономить время вашей жизни.

В рамках specs атрибут, а. yaml invalid ошибка немедленно появится в вашем конвейере, если переменная отсутствует.

specsАтрибут позволяет создавать многократно используемые задания, избегая дублирования заданий и, что наиболее важно, раньше обнаруживая ошибки. С помощью этого атрибута вы можете легко получить описание всех параметров задания и определить, какие из них являются наиболее важными.

Подводя итог нашему примеру, с specs атрибут, который вы начинаете с определения всех ваших параметров в spec.inputsсостав:

spec:
  inputs:
    my-service:
    my-image: 
---

Благодаря этой спецификации, записанной в начале вашего файла yaml, пользователи могут легко увидеть все параметры. В этом случае эти два параметра должны быть установлены, иначе в вашем конвейере появится ошибка.

Вы можете указать значение по умолчанию для своих параметров. Рабочие места, которые называют вашей работой, не могут определить my-imageпеременная.

spec:
  inputs:
    my-service:
    my-image: 
      default: "my-image:latest"
---

В заданиях новый способ использования переменной — заключить ее в две квадратные скобки, например $[[ inputs.my-service ]].

deploy-cloud-run-services:
[...]
script: 
gcloud run deploy $[[ inputs.my-service ]]" --image $[[ inputs.my-image ]]"

Каталог CI/CD

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

Эта особенность уже исследована. Я имею в виду, в частности, R2DevOps (который является партнером GitLab) и Orange, которые планируют продолжить этот проект.

GitLab работает над собственным каталогом, но существуют некоторые проблемы, которые трудно решить: как документировать шаблоны? Как вы их версионируете? Как вы поддерживаете эти шаблоны? Для получения дополнительной информации вы можете обратиться на эту страницу: https://docs.gitlab.com/ee/architecture/blueprints/ci_pipeline_comComponents/