Частенько ребята с LF стали приходить с такой проблемой:

stages:
  - deploy
variables:
  ENVIRONMENT:
    description: "Deployment environment"
    value: "N/A"
    options:
      - "N/A"
      - "STAGE"
      - "PRODUCTION"
deploy:
  stage: deploy
  script:
    - echo "Выбрано окружение:" "${ENVIRONMENT}"
  rules:
    - when: manual

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

ЧИТАТЬ ПЕРВЫМ В ТЕЛЕГРАМ   ЧИТАТЬ ПЕРВЫМ В MAX

НО — этот список перестал появляться. Причем избрано, у кого-то есть, у кого-то хуй с маслом.

Ошибок синтаксиса в ямликах нет, каких-то разумных сообщений и наводок от гитлаба тоже нет. Чё делать?

Решение

Идем: Settings → CI/CD → Variables и кликаем в радио-батон — Developer.

Всё! Теперь выпадающие списки вновь начинают работать.

А еще людей смущает новая штука inputs, которая совсем недавно появилась. Работает она с 17й версии.

spec:
  inputs:
    environment:
      description: "Куда деплоим?"
      type: string
      default: "N/A"
      options:
        - "N/A"
        - "STAGE"
        - "PRODUCTION"
---
stages:
  - deploy

deploy:
  stage: deploy
  rules:
    - when: manual
  script:
    - echo "Выбрано окружение: $[[ inputs.environment ]]"

Оно будет пиздеть во внутреннем редакторе - Incorrect type. Expected "string | array".yaml-schema, но будет работать если запустить пайплайн.

Ошибка возникает, потому, что Pipeline Editor использует старый YAML-валидатор. Так что, не обращай внимание на этот пиздёж.

А зачем нам этот input ведь с options и так всё работает?

Ну хотя бы из-за типизированных параметров:

type: string | number | boolean | array

То есть:

• можно сделать чекбокс (boolean)
• можно сделать список (array)
• можно сделать ограничение по диапазону (number)
• можно сделать строгие варианты (options)
• можно сделать regex-валидацию

А обычный variables такого не умеют. GitLab постепенно превращает CI в настоящий «Pipeline as Functions».

Например, в проекте А:

spec:
  inputs:
    env:
      type: string
      options: [stage, prod]
--
deploy-job:
  script: deploy_to $[[ inputs.env ]]

И проекте B можно вызвать:

deploy:
  trigger:
    project: A
    inputs:
      env: prod

Это как вызов функции с аргументом.

Что еще:

• Inputs работают даже при trigger-пайплайнах
• Inputs могут быть required
• Inputs отображаются отдельно и аккуратно в UI
• Inputs часть нового стандарта GitLab CI Components

Короче одни плюсы. Но есть большое НООООО!

Это пиздец усложняет процесс разработки и отладку пайплайна.

Да, стало удобнее и гибче, но всё это превращается в безумное ООП, где без базы и документации к проекту — ты хуй разберешься.

Пока тебе хватает обычных options используй их. Не лезь в это ООП, оно пока рано и избыточно, особенно если ты новичок.

Изучай!

Как говорится — и не такие метели в ебало летели!

Комментарии