werf представляет собой новое поколение CI/CD-инструментов, объединяющих в одном инструменте, который можно легко подключить к любой существующей системе CI/CD, сборку, деплой и очистку. Это возможно потому, что werf следует установленным концепциям таких систем.
werf интегрируется с CI/CD системами используя команду werf ci-env. Эта команда осуществляет сбор информации об окружении, в котором выполняется werf в рамках процесса CI/CD системы, и настраивает соответствующие параметры своей работы, устанавливая переменные окружения. Далее, такие переменные окружения будут упоминаться как ci-env или ci-env переменные. Т.е. задача команды werf ci-env — получить информацию от CI/CD системы и настроить переменные окружения (ci-env переменные) для дальнейшего запуска других команд werf.
Далее мы рассмотрим подробнее:
- Что такое ci-env переменные — какую информацию werf собирает в CI/CD системе и зачем;
 - Режимы тегирования при использовании ci-env переменных — о различиях в доступных режимах тегирования образов;
 - Как работают ci-env переменные — как нужно использовать команду 
werf ci-envи как она влияет на другие команды werf; - Полный список ci-env переменных и возможности по их настройке — рассмотрим все ci-env переменные, а также то, как их можно настраивать для вашего особого случая.
 
Что такое ci-env переменные
С помощью команды werf ci-env, werf получает информацию от CI/CD системы и устанавливает режимы дальнейшей работы для достижения следующих задач:
- Интеграция с Docker registry;
 - Интеграция с Git;
 - Интеграция с настройками CI/CD pipeline;
 - Интеграция с настройками CI/CD;
 - Настройка режима работы в CI/CD системе.
 
Интеграция с Docker registry
Обычно при работе задания в CI/CD системе, она устанавливает для каждого задания:
- Адрес Docker registry.
 - Данные авторизации для доступа к Docker registry.
 
Команда werf ci-env должна обеспечить для последующих команд авторизацию в обнаруженном Docker registry с использованием также обнаруженных данных авторизации. Читайте подробнее об авторизации в Docker registry ниже. В результате должна быть установлена переменная окружения  DOCKER_CONFIG=PATH_TO_TMP_CONFIG.
Адрес Docker registry, передаваемый CI/CD системой, будет нужен в качестве значения параметра --images-repo при выполнении некоторых команд. Поэтому, в результате выполнения werf ci-env должна быть установлена переменная окружения WERF_IMAGES_REPO=DOCKER_REGISTRY_REPO. Это позволит запускать werf в рамках задания CI/CD системы (например, для публикации, деплоя или очистки) не передавая явно значение Docker registry через параметр --images-repo, а позволит брать его из переменной окружения ($WERF_IMAGES_REPO)
Интеграция с Git
Обычно в CI/CD системах работающих с git, запуск каждого задания выполняется в состоянии git-репозитория переключенного на конкретный коммит (иначе — detached commit state). Необходимые значения коммита, тега или ветки передаются в CI-задание через переменные окружения.
Команда werf ci-env определяет из переменных окружения CI-задания данные коммита, тега или ветки, и настраивает окружение для дальнейшей работы werf таким образом, чтобы werf смог тегировать образы, описанные в файле конфигурации werf.yaml, с учетом выбранной схемы тегирования. Читай подробнее о схемах тегирования ниже.
В результате выполнения команды werf ci-env должна быть установлена переменная окружения режима тегирования, WERF_TAG_GIT_TAG=GIT_TAG или WERF_TAG_GIT_BRANCH=GIT_BRANCH.
Интеграция с настройками CI/CD pipeline
При деплое werf может добавлять любую информацию к ресурсам Kubernetes, используя их аннотации и лейблы. Обычно CI/CD системы в окружении CI-задания предоставляют такую информацию, как ссылка на страницу проекта, ссылка на само CI-задание, pipeline id и другую информацию.
Команда werf ci-env получает из переменных окружения CI-задания ссылку на проект в CI/CD системе и настраивает окружение таким образом, чтобы при дальнейшем деплое с помощью werf в рамках этого CI-задания, эта информация была встроена в каждый ресурс Kubernetes.
Команда werf ci-env получает из переменных окружения CI-задания ссылку на проект в CI/CD системе и настраивает окружение таким образом, чтобы эта информация была добавлена в аннотации каждого ресурса Kubernetes, разворачиваемого с помощью werf при деплое в рамках текущего CI-задания.
Имя аннотации зависит от используемой CI/CD системы и формируется следующим образом: "project.werf.io/CI_CD_SYSTEM_NAME-url": URL.
В результате выполнения команды werf ci-env должна быть установлена переменная окружения WERF_ADD_ANNOTATION_PROJECT_GIT="project.werf.io/git": URL.
werf автоматически добавляет и другие аннотации, а также позволяет добавлять пользовательские лейблы и аннотации, читай подробнее об этом в соответствующем разделе по деплою.
Интеграция с настройками CI/CD
В CI/CD системах используется понятие окружения (environment). Окружение может логически объединять хосты, параметры доступа, информацию о подключении к кластеру Kubernetes, параметры CI-заданий (с помощью переменных окружения например) и другую информацию. Часто используемые окружения, например, это: development, staging, testing, production, а также динамические окружения — review environments. werf также использует понятие окружение в процессе деплоя.
Команда werf ci-env анализирует текущее окружение CI-задания и дополняет его таким образом, чтобы последующие выполняемые в рамках CI-задания команды werf автоматически получили название соответствующего окружения. Если CI/CD система предоставляет, в том числе и слагифицированную версию имени окружения, то выбирается именно она.
В результате выполнения команды werf ci-env должна быть установлена переменная окружения WERF_ENV=ENV.
Настройка режима работы в CI/CD системе
Команда werf ci-env настраивает политики очистки следующим образом:
- Хранить не более чем 10 образов, собранных для git-тегов. Такое поведение определяется установкой переменной окружения 
WERF_GIT_TAG_STRATEGY_LIMIT=10; - Хранить образы собранные для git-тегов не более чем 30 дней. Такое поведение определяется установкой переменной окружения 
WERF_GIT_TAG_STRATEGY_EXPIRY_DAYS=30. 
Если CI/CD система поддерживает вывод текста разных цветов, то команда werf ci-env должна устанавливать переменную окружения WERF_LOG_COLOR_MODE=on.
По умолчанию, werf не выводит, например, в момент сборки папку проекта, где запущен процесс сборки.
Команда werv ci-env устанавливает переменную окружения WERF_LOG_PROJECT_DIR=1, в результате чего, при запуске команд werf будет выводиться текущая папка проекта.
Такое поведение удобно для отладки, т.к. позволяет концентрировать больше информации о работе CI-задания в одном месте — логе CI-задания.
Команда werf ci-env включает т.н. уничтожитель процессов (process exterminator), который выключен по умолчанию. Некоторые CI/CD системы прекращают работу запущенных в рамках CI-задания процессов посылая сигнал SIGKILL. Это происходит, например, когда пользователь нажимает кнопку отмены задания. В этом случае, процессы порожденные в рамках выполнения CI-задания будут продолжать работать до их завершения. При включенном уничтожителе процессов, werf постоянно отслеживает статус родительского процесса, и в случае его завершения, также прерывает свою работу. Такое поведение определяется установкой переменной окружения  WERF_ENABLE_PROCESS_EXTERMINATOR=1.
Команда werf ci-env включает ширину логирования в 100 символов, подобранную экспериментально, как удовлетворяющую большинству случаев работы с использованием современных экранов.
Такое поведение определяется установкой переменной окружения WERF_LOG_TERMINAL_WIDTH=100
Режимы тегирования при использовании ci-env переменных
Режим тегирования определяет то, как образ, описанный в файле конфигурации werf.yaml и собранный werf, будет тегироваться в процессе его публикации.
stages-signature
Werf использует так называемую сигнатуру стадий для тегирования результирующих образов. Каждый образ объявленный в werf.yaml в общем виде будет иметь свою сигнатуру стадий, которая зависит от содержимого этого образа и от истории правок в git, которая привела к этому содержимому.
Больше информации о тегировании с использованием сигнатуры стадий доступно в статье про процесс публикации образов. С данной стратегией тегирования werf автоматически активирует опцию --tag-by-stages-signature=true для команды werf publish.
Данный режим тегирования включен по умолчанию и является рекомендуемым режимом. Если не указывать опцию --tagging-strategy команды werf ci-env, то werf автоматически активирует стратегию тегирования stages-signature, также пользователь может явно указать опцию --tagging-strategy=stages-signature.
tag-or-branch
В этом режиме, для тегирования образа, определенного в файле конфигурации werf.yaml, будет использовано имя git-тега или git-ветки.
Образ, относящийся к соответствующему git-тегу или git-ветке будет храниться в Docker registry в соответствии с политиками очистки.
Этот режим автоматически определяет, какой параметр, --tag-git-tag или --tag-git-branch, нужно использовать в дальнейшем при публикации и деплое. В результате устанавливаются соответствующие переменные окружения, которые используются в дальнейшем в процессах публикации и деплоя.
Чтобы выбрать данный режим, необходимо указать параметр --tagging-strategy=tag-or-branch при вызове команды werf ci-env.
Если имя используемого git-тега или git-ветки не удовлетворяет regex-шаблону
^[\w][\w.-]*$либо содержит более чем 128 символов, werf применяет к имени слагификацию.
Например:
- имя ветки
 developer-featureдопустимо, и не будет изменено;- имя ветки
 developer/featureне допустимо и в результате имя тжга будет —developer-feature-6e0628fc.
Как работают ci-env переменные
Команда werf ci-env возвращает список переменных окружения, необходимый для работы дальнейших команд werf. Читай подробнее об этом далее.
Команда werf ci-env должна вызываться в самом начале CI-задания CI/CD системы, перед любыми другими командами werf.
ЗАМЕЧАНИЕ Команда werf ci-env возвращает bash-скрипт, команды которого экспортируют необходимые переменные окружения werf. Поэтому, применение команды werf ci-env подразумевает использование ее вывода в bash-команде source. Например:
source $(werf ci-env gitlab --verbose --as-file)
werf build-and-publish
Использование такой конструкции также выводит экспортируемые значения в терминал.
Пример вывода команды werf ci-env (без направления вывода в source):
### DOCKER CONFIG
echo '### DOCKER CONFIG'
export DOCKER_CONFIG="/tmp/werf-docker-config-204033515"
echo 'export DOCKER_CONFIG="/tmp/werf-docker-config-204033515"'
### IMAGES REPO
echo
echo '### IMAGES REPO'
export WERF_IMAGES_REPO="registry.domain.com/project/x"
echo 'export WERF_IMAGES_REPO="registry.domain.com/project/x"'
### TAGGING
echo
echo '### TAGGING'
export WERF_TAG_GIT_TAG="v1.0.3"
echo 'export WERF_TAG_GIT_TAG="v1.0.3"'
### DEPLOY
echo
echo '### DEPLOY'
export WERF_ENV="dev"
echo 'export WERF_ENV="dev"'
export WERF_ADD_ANNOTATION_PROJECT_GIT="project.werf.io/git=https://gitlab.domain.com/project/x"
echo 'export WERF_ADD_ANNOTATION_PROJECT_GIT="project.werf.io/git=https://gitlab.domain.com/project/x"'
export WERF_ADD_ANNOTATION_CI_COMMIT="ci.werf.io/commit=b9a1ddd366aa6a20a0fd43fb6612f349d33465ff"
echo 'export WERF_ADD_ANNOTATION_CI_COMMIT="ci.werf.io/commit=b9a1ddd366aa6a20a0fd43fb6612f349d33465ff"'
export WERF_ADD_ANNOTATION_GITLAB_CI_PIPELINE_URL="gitlab.ci.werf.io/pipeline-url=https://gitlab.domain.com/project/x/pipelines/43107"
echo 'export WERF_ADD_ANNOTATION_GITLAB_CI_PIPELINE_URL="gitlab.ci.werf.io/pipeline-url=https://gitlab.domain.com/project/x/pipelines/43107"'
export WERF_ADD_ANNOTATION_GITLAB_CI_JOB_URL="gitlab.ci.werf.io/job-url=https://gitlab.domain.com/project/x/-/jobs/110681"
echo 'export WERF_ADD_ANNOTATION_GITLAB_CI_JOB_URL="gitlab.ci.werf.io/job-url=https://gitlab.domain.com/project/x/-/jobs/110681"'
### IMAGE CLEANUP POLICIES
echo
echo '### IMAGE CLEANUP POLICIES'
export WERF_GIT_TAG_STRATEGY_LIMIT="10"
echo 'export WERF_GIT_TAG_STRATEGY_LIMIT="10"'
export WERF_GIT_TAG_STRATEGY_EXPIRY_DAYS="30"
echo 'export WERF_GIT_TAG_STRATEGY_EXPIRY_DAYS="30"'
### OTHER
echo
echo '### OTHER'
export WERF_LOG_COLOR_MODE="on"
echo 'export WERF_LOG_COLOR_MODE="on"'
export WERF_LOG_PROJECT_DIR="1"
echo 'export WERF_LOG_PROJECT_DIR="1"'
export WERF_ENABLE_PROCESS_EXTERMINATOR="1"
echo 'export WERF_ENABLE_PROCESS_EXTERMINATOR="1"'
export WERF_LOG_TERMINAL_WIDTH="95"
echo 'export WERF_LOG_TERMINAL_WIDTH="95"'
Передача CLI-параметров через переменные окружения
Любой параметр любой команды werf (кроме команды ci-env) который может быть передан через CLI, также может быть установлен с помощью переменных окружения.
Существует общее правило соответствия параметра CLI переменной окружения: переменная окружения имеет префикс WERF_, состоит из заглавных букв и символа подчеркивания _ вместо дефиса -.
Примеры:
--tag-git-tag=mytagаналогичен использованиюWERF_TAG_GIT_TAG=mytag;--env=stagingаналогичен использованиюWERF_ENV=staging;--images-repo=myregistry.myhost.com/project/xаналогичен использованиюWERF_IMAGES_REPO=myregistry.myhost.com/project/x;- … и.т.д.
 
Исключением из этого правила являются параметры --add-label и --add-annotation, которые могут быть указаны несколько раз. Чтобы указать эти параметры используя переменные окружения, нужно использовать следующий шаблон: WERF_ADD_ANNOTATION_<ARBITRARY_VARIABLE_NAME_SUFFIX>="annoName1=annoValue1". Например:
export WERF_ADD_ANNOTATION_MYANNOTATION_1="annoName1=annoValue1"
export WERF_ADD_ANNOTATION_MYANNOTATION_2="annoName2=annoValue2"
export WERF_ADD_LABEL_MYLABEL_1="labelName1=labelValue1"
export WERF_ADD_LABEL_MYLABEL_2="labelName2=labelValue2"
Обратите внимание, что суффиксы _MYANNOTATION_1, _MYANNOTATION_2, _MYLABEL_1, _MYLABEL_2 не влияют на имена или значения аннотаций и меток, а необходимы только для получения уникальных переменных окружения.
Авторизация в Docker registry
Как уже упоминалось в разделе интеграции с Docker registry, werf выполняет автоматическую авторизацию в обнаруженном Docker registry.
Выполнение команды werf ci-env всегда приводит к созданию временного файла конфигурации Docker.
Временный файл конфигурации Docker необходим для возможности параллельной работы CI-заданий, чтобы они не мешали друг другу. К тому-же, использование временного файла конфигурации является более безопасным вариантом, чем регистрация в Docker registry используя общий системный файл конфигурации (~/.docker).
Если определена переменная окружения DOCKER_CONFIG либо присутствует папка ~/.docker, werf копирует оттуда данные в новый временный файл конфигурации. Поэтому, уже существующие или выполненные непосредственно перед вызовом werf ci-env регистрации в Docker registry (docker login) будут активны и доступны во временном файле конфигурации Docker.
После создания нового файла конфигурации, werf выполняет дополнительную регистрацию в обнаруженном из окружения CI-задания Docker registry.
Как результат процедуры интеграции с Docker registry, команда werf ci-env экспортирует в переменной окружения DOCKER_CONFIG путь к временному файлу конфигурации Docker.
Этот файл конфигурации Docker будет использован впоследствии любой выполняемой командой werf, а также может быть использован командой docker login для выполнения дополнительных регистраций исходя из ваших нужд.
Полный список ci-env переменных
Выполнение команды werf ci-env приводит к выводу списка переменных окружения для их последующего экпорта.
Чтобы настроить эти переменные по особенному, исходя из вашей ситуации, вы можете определить необходимую переменную (с префиксом имени WERF_) до выполнения команды werf ci-env. После запуска werf ci-env, werf обнаружит установленную переменную окружения и не будет переопределять ее значение, а также будет использовать ее при необходимости как есть. Вы можете добиться этого как непосредственно экспортируя переменные в shell-сессии перед вызовом werf ci-env, так и устанавливая переменные окружения в настройках проекта в CI/CD системе.
Командой werf ci-env выводятся перечисленные далее переменные окружения.
DOCKER_CONFIG
Путь к новому временному файлу конфигурации Docker сгенерированный командой werf ci-env.
WERF_STAGES_STORAGE
Согласно процедуре интеграции с Docker registry, команда werf ci-env определяет Docker registry и устанавливает параметр --stages-storage, используя переменную окружения WERF_STAGES_STORAGE.
WERF_IMAGES_REPO
Согласно процедуре интеграции с Docker registry, команда werf ci-env определяет Docker registry и устанавливает параметр --images-repo, используя переменную окружения WERF_IMAGES_REPO.
WERF_TAG_BY_STAGES_SIGNATURE
Если опция --tagging-strategy=stages-signature установлена явно или не указана, werf использует стратегию тегирования stages-signature. Werf устанавливает переменную окружения WERF_TAG_BY_STAGES_SIGNATURE=true в этом случае.
WERF_TAG_GIT_TAG
Согласно процедуре интеграции с Git, команда werf ci-env определяет, запущено ли задание для git-тега, и в случае положительного результата устанавливает параметр --tag-git-tag, используя переменную окружения WERF_TAG_GIT_TAG.
WERF_TAG_GIT_BRANCH
Согласно процедуре интеграции с Git, команда werf ci-env определяет, запущено ли задание для git-ветки, и в случае положительного результата устанавливает параметр --tag-git-branch, используя переменную окружения WERF_TAG_GIT_BRANCH.
WERF_ENV
Согласно процедуре интеграции с настройками CI/CD, команда werf ci-env определяет имя окружения и устанавливает параметр --env, используя переменную окружения WERF_ENV.
WERF_ADD_ANNOTATION_PROJECT_GIT
Согласно процедуре интеграции с настройками CI/CD pipeline, команда werf ci-env определяет web-адрес проекта и устанавливает параметр --add-annotation, используя переменную окружения WERF_ADD_ANNOTATION_PROJECT_GIT.
WERF_ADD_ANNOTATION_CI_COMMIT
Согласно процедуре интеграции с настройками CI/CD pipeline, команда werf ci-env определяет хэш git-коммита и устанавливает параметр --add-annotation, используя переменную окружения WERF_ADD_ANNOTATION_CI_COMMIT.
WERF_GIT_TAG_STRATEGY_LIMIT
Согласно процедуре настройки режима работы в CI/CD системе, команда werf ci-env устанавливает параметр --git-tag-strategy-limit, используя переменную окружения WERF_GIT_TAG_STRATEGY_LIMIT.
WERF_GIT_TAG_STRATEGY_EXPIRY_DAYS
Согласно процедуре настройки режима работы в CI/CD системе, команда werf ci-env устанавливает параметр --git-tag-strategy-expiry-days, используя переменную окружения WERF_GIT_TAG_STRATEGY_EXPIRY_DAYS.
WERF_LOG_COLOR_MODE
Согласно процедуре настройки режима работы в CI/CD системе, команда werf ci-env устанавливает параметр --log-color-mode, используя переменную окружения WERF_LOG_COLOR_MODE.
WERF_LOG_PROJECT_DIR
Согласно процедуре настройки режима работы в CI/CD системе, команда werf ci-env устанавливает параметр --log-project-dir, используя переменную окружения WERF_LOG_PROJECT_DIR.
WERF_ENABLE_PROCESS_EXTERMINATOR
Согласно процедуре настройки режима работы в CI/CD системе, команда werf ci-env устанавливает параметр --enable-process-exterminator, используя переменную окружения WERF_ENABLE_PROCESS_EXTERMINATOR.
WERF_LOG_TERMINAL_WIDTH
Согласно процедуре настройки режима работы в CI/CD системе, команда werf ci-env устанавливает параметр --log-terminal-width, используя переменную окружения WERF_LOG_TERMINAL_WIDTH.