TLDR-ответ;
pipelines в круге ci по сути являются триггерами - запускают все рабочие процессы для определенного c репо / ветви / тега, в том числе, когда круговые автозапуски из переменные конвейера push / merge et c.
, по-видимому, являются переменными, которые требуют объявления в config.yml и значений по умолчанию. Их значения могут быть установлены только при запуске «конвейера» через API 2.0.
Пример триггера через API 2.0 [github]: (ПРИМЕЧАНИЕ: требуется личный токен [не проект])
curl -u ${CIRCLECI_TOKEN}: -X POST --header "Content-Type: application/json" -d '{
"branch": "feat",
"parameters": {
"image-tag": "4.8.2"
}
}' https://circleci.com/api/v2/project/gh/<org>/<repo>/pipeline
Длинный ответ
Если вы чем-то похожи на меня, вы можете думать о слове pipeline в контексте CI как о иерархии рабочих мест с зависимостями между ними и Возможность передавать данные от одного шага к следующему. Эта функция существует в круге ci и является довольно мощной (за исключением того, что передача данных является довольно неудобной), но она называется workflow. Таким образом, оставляя вопрос о том, что означает круг ci с «конвейером», после того, как он немного поиграл с его запуском и просмотрел разные части документа, я пришел к выводу, что его, вероятно, следовало бы назвать «триггером» или «выполнением рабочего процесса» или чем-то в этом роде. По сути, он описывает запуск всех рабочих процессов в данной ветви / теге, в том числе, когда этот триггер автоматически c посредством push / merge.
Нельзя использовать конвейер для запуска задания с параметрами или даже для запуска задания вообще, если только вы сначала не заключите каждое такое задание в конвейер и не создадите условную схему, чтобы не запускать другие рабочие процессы .
Почему даже go там?
Я до сих пор не уверен, что это стоит того, чтобы быть честным, но в основном нас гонят:
- Не оставайтесь на старых технологиях (и скоро их выбросят)
- Сферы - довольно хороший способ DRY конвейеров, который работает только в конфигурации 2.1
Проблема?
Вариант использования 1. По сути, у нас есть задание, которое необходимо выполнить после развертываний в 3 разных репозиториях, и вместо того, чтобы вставлять копии и поддерживать код в 3 местах, мы поместил задание в 4-й репо и, используя circleci API 1.1, запустил его с входными параметрами из разных репо. Прекрасно работает в конфиге 2.0 circleci. Также невозможно достичь в конфигурации 2.1 после того, как круг ci ввел регрессию, чтобы больше не поддерживать запуск задания с параметрами.
Вариант использования 2. В некоторых других случаях полезно запускать с помощью параметров, если, скажем: выполнение задания занимает 2 часа, и вам не нужно ждать, чтобы что-то проверить в вашем конвейере.
Вариант использования 3: сбой задания 2, и вам нужно исправить его перед ручным повторным запуском с выводом задания 1.
Для простоты рассмотрим рабочий процесс 2 заданий:
+-------+ +-------+
| Job 1 | -> | Job 2 |
+-------+ +-------+
И мы хотим иметь возможность:
- Передавать переменные из задания 1 в задание 2
- Выполнять задание 2 через API, передавая параметры заданию
В circleci API 1.1 это просто вопрос передачи параметров в задание (через API), и они автоматически преобразуются в переменные окружения. Просто.
С включенными «конвейерами» и в конфигурации 2.1, кажется, нет элегантного способа добиться этого. Хотя это несколько облегчается наличием шаров и сохранением полного рабочего процесса в 1 репо (по крайней мере, вариант использования 1). Однако существует раздутый и хакерский способ сделать это с помощью конвейеров 2.1, который сводится к (пример PO C ниже):
- Убедитесь, что есть параметр конвейера, который позволяет всем "нормальным" рабочим процессам не run.
- Добавить параметр конвейера для запуска задания по требованию 2
- Добавить параметры конвейера для фактических параметров, которые необходимо передать в задание 2.
- Создать задание 3, который принимает параметры конвейера и передает их в задание 2 в качестве переменных env.
- Создайте рабочий процесс, который запускает задание 3, а затем задание 2, когда переменная по требованию установлена
Awkward ? О да. Я могу только догадываться, что у круга ci были некоторые другие варианты использования для введения переменных конвейера, потому что это просто не очень удобно.
Заключение
Я до сих пор не могу понять, как вы "должны" использовать конвейерные переменные. Возможно, в будущем у официальных документов будет больше ясности по этому вопросу.
Я действительно вижу необходимость в конвейерных переменных, и они могут быть довольно мощными, но их ограничения приводят к некоторой неловкости, по крайней мере для наших случаев использования. Меня больше всего раздражают следующие ограничения:
- Нет способа (я думаю) установить переменную конвейера в задании 1, получить к нему доступ из задания 2.
- Нет способа (я думаю ) для установки конвейерной переменной в определении задания.
- Переменные должны быть предопределены.
- Нет способа выборочно запустить только один рабочий процесс
- Нет способа выборочно запустить только одно задание
Рабочий пример PO C config.yml для запуска job2 с использованием вывода из job1 или по требованию с параметрами, отправленными в пользовательский конвейер, пользовательский рабочий процесс и промежуточное задание 3:
version: 2.1
# Pipeline parameters
parameters:
workflow_ondemand:
type: boolean
default: false
workflow_job2_ondemand:
type: boolean
default: false
workflow_job2_param1_version:
type: string
default: "invalid version"
workflows:
version: 2
normal-workflow:
unless: << pipeline.parameters.workflow_ondemand >>
jobs:
- job1
- job2:
requires: [job1]
workflow-job2-ondemand:
when: << pipeline.parameters.workflow_job2_ondemand >>
jobs:
- job3
- job2:
requires: [job3]
# Trigger with:
#
# curl -u ${CIRCLECI_TOKEN}: -X POST --header "Content-Type: application/json" -d '{
# "branch": "feat",
# "parameters": {
# "workflow_ondemand": true,
# "workflow_job2_ondemand": true,
# "workflow_job2_param1_version": "version1"
# }
# }' https://circleci.com/api/v2/project/gh/<org>/<repo>/pipeline
jobs:
job1:
docker:
- image: circleci/node:latest
steps:
- run:
name: Fake build and generate random version number
command: |
echo export VERSION=$((1 + RANDOM % 100)) >> /tmp/.env
source /tmp/.env
echo "Version in job1: ${VERSION}"
- persist_to_workspace:
root: /tmp/
paths: ['.env']
job2:
docker:
- image: circleci/node:latest
steps:
- attach_workspace:
at: /tmp
- run:
name: "Load and print version from previous step"
command: |
source /tmp/.env
echo "Version in job2: ${VERSION}"
job3:
docker:
- image: circleci/node:latest
environment:
VERSION: << pipeline.parameters.workflow_job2_param1_version >>
steps:
- run:
name: "Save parameter value to .env"
command: |
echo export VERSION=${VERSION} >> /tmp/.env
echo "Version in job3: ${VERSION}"
- persist_to_workspace:
root: /tmp/
paths: ['.env']