Как мигрировать с v1.1 на v1.2

Чтобы мигрировать ваш проект с werf v1.1 на werf v1.2 следуйте приведенным ниже шагам.

ВНИМАНИЕ! Существуют такие конфигурации v1.1, которые используют директивы mount from build_dir и mount fromPath для кеширования внешних зависимостей приложения (зависимости, описываемые в таких файлах, как Gemfile, package.json, go.mod и т.п.). Такие директивы mount всё ещё поддерживаются в werf v1.2, однако не рекомендуются к использованию и по умолчанию выключены режимом гитерминизма (за исключением mount from tmp_dir — данная директива не ограничена к использованию), потому что использование этих директив может привести к ненадёжным, недетерминированным сборкам, зависимым от сборочных хостов. Для таких конфигураций планируется добавление новой возможности хранения такого кеша в Docker-образах. Данная фича планируется к добавлению в v1.2, но еще не реализована.

Поэтому, если ваша конфигурация использует такие mounts, то предлагаются следующие варианты:

Продолжить использование версии v1.1, пока данная улучшенная возможность кеширования не будет добавлена в werf v1.2.
Удалить использование таких mounts и подождать добавления улучшенной возможности кеширования в werf v1.2.
Включить используемые mounts в werf v1.2 с помощью конфигурационного файла werf-giterminism.yaml (не рекомендуется).

Ключевые моменты

1. Используйте стратегию тегирования content-based

Стратегия тегирования content-based — это выбор по умолчанию и единственно доступный вариант, используемый в werf во время процесса деплоя.

Удалите параметр --tagging-strategy команды werf ci-env.
Удалите опции --tag-custom, --tag-git-tag, --tag-git-branch, и --tag-by-stages-signature.

В случае, если требуется, чтобы определённый Docker-тег для собранного образа существовал в container registry для использования вне werf, тогда допустимо использование параметра --save-build-report (и, опционально, --build-report-path) следующим образом:

werf build/converge --save-build-report --repo REPO;
docker pull $(cat .werf-build-report.json | jq -r .Images.IMAGE_NAME_FROM_WERF_YAML.DockerImageName);
docker tag $(cat .werf-build-report.json | jq -r .Images.IMAGE_NAME_FROM_WERF_YAML.DockerImageName) REPO:mytag;
docker push REPO:mytag.

2. Используйте команду `converge` вместо команды `build-and-publish`

Теперь вместо werf deploy должна использоваться команда werf converge. Она используется сразу для сборки, публикации и деплоя приложения в Kubernetes и поддерживает те же параметры, что и werf deploy.

Изменения в командах (для справки):

Команда werf build-and-publish удалена.
Добавлена команда werf build, использование которой опционально.
werf converge самостоятельно собирает и публикует в container registry недостающие образы.
werf build также может быть использована на стадии prebuild в CI/CD pipeline вместо werf build-and-publish.

3. Используйте параметр `--repo` вместо параметров `--stages-storage` и `--images-repo`

Команда werf converge хранит и собираемые образы и их стадии в container registry. Для указания хранилища, которое будет использоваться для хранения образов и стадий, теперь необходимо указать один параметр --repo вместо двух используемых ранее в v1.1 --stages-storage и --images-repo.

Аналогично и с переменными окружения, используемыми ранее: вместо WERF_STAGES_STORAGE и WERF_IMAGES_REPO теперь используется одна переменная WERF_REPO.

4. Измените Helm-шаблоны

Вместо werf_container_image используйте .Values.werf.image.IMAGE_NAME:

 spec:
   template:
     spec:
       containers:
         - name: main
           image: {{ .Values.werf.image.myimage }}

ВАЖНО! Убедитесь, что используете apiVersion: v2! Это необходимо, чтобы разрешить описание зависимостей непосредственно в .helm/Chart.yaml вместо .helm/dependencies.yaml.

Изменения в Helm-шаблонах (для справки):

Полностью удалена шаблонная функция werf_container_env.
Необходимо использовать .Values.werf.env вместо .Values.global.env.
Необходимо использовать .Values.werf.namespace вместо .Values.global.namespace.
Если в имени образа содержится дефис (-), то запись должна быть такого вида: image: '{{ index .Values.werf.image "IMAGE-NAME" }}'.
Необходимо использовать "werf.io/replicas-on-creation": "NUM" вместо "werf.io/set-replicas-only-on-creation": "true".

ВАЖНО! "NUM" должно быть указано строкой, а не как число NUM, иначе аннотация будет проигнорирована.

ВАЖНО! При использовании данной аннотации необходимо удалить явное определение поля spec.replicas, больше информации в changelog.

5. Используйте `.helm/Chart.lock` для сабчартов

В соответствии с режимом гитерминизма werf не позволяет держать некоммитнутую директорию .helm/charts/. Для использования сабчартов необходимо определить dependencies в .helm/Chart.yaml следующим способом:

 # .helm/Chart.yaml
 apiVersion: v2
 dependencies:
   - name: redis
     version: "12.7.4"
     repository: "https://charts.bitnami.com/bitnami"

ВАЖНО! Убедитесь, что используете apiVersion: v2! Это необходимо, чтобы разрешить описание зависимостей непосредственно в .helm/Chart.yaml вместо .helm/dependencies.yaml.

Далее выполните следующие шаги:

Добавьте директорию .helm/charts/ в .gitignore.
Запустите werf helm dependency update .helm для создания файла .helm/Chart.lock и директории .helm/charts/ в локальной файловой системе.
Коммитните .helm/Chart.lock в Git-репозиторий проекта.

werf автоматически скачает указанные сабчарты в кеш и загрузит файлы сабчартов во время команды werf converge (и других высокоуровневых командах, которые используют Helm-чарт).

6. Используйте очистку на основе истории Git

Удалите опцию --git-history-based-cleanup-v1.2 — теперь поведение werf cleanup по умолчанию совпадает с поведением v1.1 с данной опцией. Больше информации по изменению [в changelog](#очистка true_relative_url }}) и в статье про cleanup.

7. Определите используемые переменные окружения в `werf-giterminism.yaml`

ЗАМЕЧАНИЕ! На самом деле использование переменных окружения в werf.yaml не рекомендуется (за исключением редких случаев), больше информации в статье.

Если в werf.yaml используются, например, переменные окружения ENV_VAR1 и ENV_VAR2, то необходимо добавить следующее описание в werf-giterminism.yaml:

# werf-giterminism.yaml
giterminismConfigVersion: 1
config:
  goTemplateRendering:
    allowEnvVariables:
      - ENV_VAR1
      - ENV_VAR2

8. Скоректируйте конфигурационный файл `werf.yaml`

Замените относительные пути для включения дополнительных шаблонов с {{ include “.werf/templates/1.tmpl” . }} на {{ include “templates/1.tmpl” . }}.
Переименуйте fromImageArtifact в fromArtifact.

ЗАМЕЧАНИЕ! Не обязательно, но желательно заменить artifact и fromArtifact на image и fromImage в данном случае. Заметка про запрет использования fromArtifact в changelog.

9. Исправьте определение нестандартной директории чарта `.helm` в `werf.yaml`

Вместо опции --helm-chart-dir используйте директиву deploy.helmChartDir файла werf.yaml следующим образом:

configVersion: 1
deploy:
  helmChartDir: .helm2

Следует рассмотреть другой вариант расположения конфигурации для вашего проекта: werf v1.2 поддерживает несколько werf.yaml в едином Git-репозитории.

Вместо переопределения нескольких разных deploy.helmChartDir в werf.yaml создаётся несколько werf.yaml в разных директориях проекта.
Каждая такая директория содержит свою директорию .helm соответственно.
werf необходимо запускать из каждой директории.
Все относительные пути, указанные в werf.yaml, будут рассчитаны относительно той директории, где лежит werf.yaml.
Абсолютные пути, указанные в директиве git.add, так и остаются абсолютными путями относительно корня Git-репозитория независимо от положения werf.yaml внутри этого репозитория.

10. Мигрируйте на Helm 3

werf v1.2 осуществляет автоматическую миграцию существующего релиза с Helm 2 на Helm 3.

Релиз Helm 2 должен иметь то же самое имя, как и вновь создаваемый релиз Helm 3.

Перед запуском процесса миграции werf проверит, что текущие шаблоны из .helm/templates рендерятся и валидируются корректно, и только после успешного рендеринга миграция будет начата.

ВАЖНО! Как только проект переехал на Helm 3 – не существует обратного пути на werf v1.1 и Helm 2.

Changelog

Данная статья содержит полный список изменений с версии v1.1.

Гитерминизм

werf вводит так называемый режим гитерминизма. Название происходит от слов git и детерминизм, что означает “детерминированный git’ом”.

Все конфигурационные файлы werf, конфигурация helm и файлы приложения werf будет читать из текущего коммита git репозитория проекта. Существует также режим разработки для упрощения локальной разработки конфигурации werf и локальной разработки приложения с использованием werf.

Больше информации о режиме доступно на странице документации.

Для конфигурации гитерминизма в werf также был добавлен новый конфигурационный файл werf-giterminism.yaml.

Локальная разработка

Follow и dev

Все высокоуровневые команды: werf converge, werf run, werf bundle publish, werf render и werf build — имеют 2 основных флага --follow и --dev для локальной разработки.

По умолчанию каждая из этих команд читает все требуемые файлы из текущего коммита git репозиторию проекта. С флагом --dev команда будет использовать все файлы из рабочей директории git проекта, включая неотслеживаемые (untracked) файлы. werf игнорирует изменения с учётом правил, описанных в .gitignore, а также правил, заданных пользователем опцией --dev-ignore=<glob> (может использоваться несколько раз).

Команда с флагом --follow будет работать в цикле, в котором:

новый коммит в рабочую директорию git проекта вызовет перезапуск команды — по умолчанию;
изменения в рабочей директории git, включая неотслеживаемые (untracked) файлы, вызовут перезапуск команды — когда флаг --follow совмещён с флагом --dev.

Внутри werf создаёт специальные коммиты для modified/tracked и staged файлов из git-индекса в ветке werf-dev-<commmit>. Кеш в режиме разработки будет привязан к этим временным коммитам и тем самым отделён от основного сборочного кеша (когда не указано флага --dev).

Поддержка composer

werf поддерживает основные команды composer. При запуске этих команд werf автоматом установит специальные переменные окружения, в которых доступны полные имена docker-образов для образов, описанных в werf.yaml:

WERF_<FORMATTED_WERF_IMAGE_NAME>_DOCKER_IMAGE_NAME=application:45f03bdd90c844eb2e61e7e01dae491588d2bdadbd195881b25be9b0-1613371915351

Например, если имеется следующий werf.yaml:

# werf.yaml
project: myproj
configVersion: 1
---
image: myimage
from: alpine

Полное имя docker-образа для myimage может быть использовано в docker-compose.yml следующим образом:

version: '3'
services:
  web:
    image: "${WERF_MYIMAGE_DOCKER_IMAGE_NAME}"

werf предоставляет следующие команды compose:

werf compose config — запуск команды docker-compose config с прокинутыми именами образов из werf.yaml;
werf compose down — запуск команды docker-compose down с прокинутыми именами образов из werf.yaml;
werf compose up — запуск команды docker-compose up с прокинутыми именами образов из werf.yaml;

Бандлы

Бандлы позволяют разделить процесс создания нового релиза кода приложения и процесс деплоя этого релиза в кластер kubernetes.
Бандлы хранятся в container registry.
Работа с бандлами предполагает 2 основных шага: 1) публикация бандла для приложения из рабочей директории git проекта в container registry; 2) деплой ранее опубликованного бандла из container registry в кластер kubernetes.
Больше информации в документации.

Переработка основного командного интерфейса и поведения команд

Переработка интерфейса

Удалена команда werf deploy. Рекомендуется использовать команду werf converge — единую команду для сборки и публикации требуемых образов в container registry и деплоя приложения в kubernetes.
- Вызов werf converge --require-built-images эмулирует поведение werf deploy: werf выходит с ошибкой если требуемые образы не будут найдены в container registry.
Удалены команды werf stages *, werf images * и werf host project *.
Более нет команды werf publish, потому что команда werf build с параметром --repo загрузит образы и все стадии, из которых они состоят, в container registry автоматически.
Более нет флагов тегирования: --tag-by-stages-signature, --tag-git-branch, --tag-git-commit, --tag-git-tag и --tag-custom, werf всегда использует поведение ранее включаемое флагом --tag-by-stages-signature.
- Принудительное использование произвольных тегов пока не поддерживается в v1.2.
- Команда werf ci-env принимает скрытый параметр --tagging-strategy по соображениям совместимости для следующего варианта вызова: werf ci-env --tagging-strategy без опции --as-file.
  - Использование данного флага должно быть удалено из всех вызовов команды werf ci-env.
  - Указанный параметр не влияет на поведение werf, поведение соответствующее ранее существовавшему флагу --tag-by-stages-signature будет использовано в любом случае.

Поведение команд werf-build и werf-converge

По умолчанию команда werf build не требует никаких аргументов и будет собирать образы используя локальный Docker-сервер в качестве хранилища.
При запуске werf build с флагом --repo registry.mydomain.org/project werf будет искать локально собранные образы и если найдёт, то загрузит их в указанный repo (лишней пересборки не будет).
Команда werf converge требует параметр --repo для работы, и, так же как werf build, автоматически загрузит в repo локально существующие образы.

Поведение команд очистки

Команды werf cleanup/purge используются только для чистки сontainer registry.
Команда werf host purge --project=<project-name> может использоваться для удаления образов проекта из локального Docker (ранее для этого можно было использовать команду werf purge).

Автоматическая сборка образов в командах верхнего уровня

Команды werf converge, werf run, werf bundle publish и werf render автоматически соберут недостающие образы, которые не существуют в container registry.
Команда werf render будет собирать образы только при передаче опционального параметра --repo.

Хранение образов в CI/CD системах

В качестве параметра --repo предполагается использование container registry привязанного к проекту.

Команда werf ci-env для GitLab CI/CD, например, сгенерирует следующий параметр: WERF_REPO=$CI_REGISTRY_IMAGE.
Указанный репозиторий --repo будет использован для хранения как собранных промежуточных стадий образа, так и финального образа (внутри эти слои переиспользуются и публикация промежуточных стадий не создаёт накладных расходов).

werf всегда хранит стадии в container registry

Команда werf converge всегда хранит образы и стадии, из которых они состоят, в container registry.
Единый параметр --repo используется для указания хранилища образов и стадий этих образов (ранее в v1.1 было 2 параметра --stages-storage и --images-repo).
Благодаря использованию content-based тегирования финальный образ совпадает с последней сборочной стадией этого образа.
- Т.к. образы состоят из набора слоёв, все эти слои всё равно хранятся в container registry.
  - Поэтому хранение промежуточных стадий в container registry вместе с image не создаёт накладных расходов.
  - Это делает процесс сборки образов в werf независимым от сборочного хоста, потому что в процессе сборки промежуточные стадии будут переиспользованы из container registry в качестве сборочного кеша.

Изменения сигнатур

Сигнатуры переименованы в дайджесты (signature => digest).
Все дайджесты уже собранных образов изменились.
Образы собранные через сборщик как Dockerfile, так и stapel, будут пересобраны.
- Другими словами сборочный кеш из v1.1 более не валиден.

Сборщик stapel

Удалена возможность кеширования каждой сборочной инструкции из werf.yaml по отдельным слоям с помощью директивы asLayers.

Опциональный параметр env

Для команд werf converge, werf render and werf bundle publish существует параметр --env.
--env влияет на имя helm релиза и kubernetes namespace также как в v1.1.
- При указании параметра --env имя helm релиза будет сгенерировано по шаблону [[ project ]]-[[ env ]] и namespace в kubernetes будет сгенерирован по такому же шаблону [[ project ]]-[[ env ]] — так же как в версии v1.1.
- Когда параметр --env не указан, werf будет использовать шаблон [[ project ]] для генерации имени helm релиза и такой же шаблон [[ project ]] для генерации namespace в kubernetes.

Новая команда werf-render

Команда werf render автоматически соберёт недостающие образы в container registry.
Данная команда позволяет воспроизвести шаблоны в точно таком же виде, как они будут сгенерированы в команде werf converge.
Команда werf render работает в режиме гитерминизма.

Helm

Helm 3

Helm 3 используется по умолчанию, и это единственная версия helm доступная для использования в v1.2.
Уже существующие релизы helm 3 будут смигрированы на helm 3 автоматически в команде werf converge при условии, что имя релиза helm 2 совпадает с именем нового релиза helm 3.
- ПРЕДУПРЕЖДЕНИЕ. Как только релиз helm 2 конвертирован в helm 3 пути назад нет.
- Прежде чем мигрировать релиз helm 2 в helm 3, команда werf converge проверит, что текущие шаблоны корректно рендерятся и валидируются.

Конфигурация

.Values.werf.image.IMAGE_NAME вместо шаблона werf_image.
Удалена функция шаблонов werf_container_env.
Загрузка всех конфигурационных файлов чарта происходит в режиме гитерминизма.
- Данный режим используется только для высокоуровневых команд вроде werf converge и werf render.
- Низкоуровневые helm-команды werf helm * работают в обычном режиме и загружают файлы из локальной файловой системы.
Окружение, переданное опцией --env, доступно для использования через .Values.werf.env.
Целевой namespace доступен для использования через .Values.werf.namespace.
Исправлен подход к использованию файла .helm/Chart.yaml. Файл .helm/Chart.yaml опционален, однако werf будет его использовать, если он существует следующим образом:
- Файл .helm/Chart.yaml берётся из git репозитория проекта, если он существует.
- Поле metadata.name перезаписывается именем проекта из werf.yaml.
- Поле metadata.version устанавливается в 1.0.0, если оно явно не определено.
Добавлено сервисное значение .Values.werf.version с версией утилиты werf, которая используется.
Поддерживается установка начального количества реплик, когда активен режим HPA для Deployment и других типов ресурсов. Необходимо установить аннотацию "werf.io/replicas-on-creation": NUM и убрать явное определение spec.replicas в шаблонах в таком случае.
- spec.replicas переопределяет werf.io/replicas-on-creation.
- Данная аннотация особенно полезна при использовании HPA, в данной статье описано почему.

Работа с сабчартами

Лок-файл с зависимостями .helm/Chart.lock должен быть коммитнут в git репозиторий проекта.
werf автоматически скачает все зависимости определённые в лок-файле.
Обычно директория .helm/charts/ должна быть добавлена в .gitignore.
Однако werf позволяет хранить зависимые чарты и в директории .helm/charts.
- Данные чарты перезапишут автоматически загруженные по .helm/Chart.lock чарты.
См. больше информации по зависимым чартам.

Удалена команда werf-helm-deploy-chart

Вместо команды werf helm deploy-chart можно использовать команды werf helm install и werf helm upgrade.

Лучшая интеграция с командами werf-helm-*

Команда werf helm template может быть использована для рендера локальных чартов даже при использовании секретов (функции шаблонов werf_secret_file).
Файлы секретов полностью поддерживаются командами werf helm *.
Дополнительные аннотации и лейблы полностью поддерживаются командами werf helm * (опции --add-annotation и --add-label).

Изменён формат сервисных значений

Удалено сервисное значение .Values.global.werf.image, вместо него используется .Values.werf.image.

Процесс деплоя

Добавлено полноценное ожидание удаления ресурсов перед выходом в командах werf dismiss и werf helm uninstall.
Wait until all release resources terminated in the werf dismiss command before exiting.

werf.yaml

Директива fromImageArtifact переименована в fromArtifact.
- ПРЕДУПРЕЖДЕНИЕ. Директива fromImageArtifact/fromArtifact не рекомендована к использованию и будет удалена в v1.3 из-за неочевидной работы механизма наложения патчей в получившейся конфигурации. Рекомендуется уже сейчас перейти на image и fromImage вместо artifact и fromArtifact.
Директивы herebyIAdmitThatFromLatestMightBreakReproducibility и herebyIAdmitThatBranchMightBreakReproducibility удалены. Теперь при использовании директив fromLatest и git.branch необходимо ослаблять правила гитерминизма, используя соответствующие директивы в werf-giterminism.yaml.
Удалена опция --helm-chart-dir, директория helm-чарта определяется в werf.yaml:
```
 configVersion: 1
 deploy:
   helmChartDir: .helm
```
Опции --allow-git-shallow-clone, --git-unshallow и --git-history-synchronization превращены в директивы werf.yaml, добавлена новая мета-секция gitWorktree. Выключено использование этих опций в команде werf ci-env: unshallow git clone происходит всегда.
Использование sprig v3 вместо v2: http://masterminds.github.io/sprig/.
Новая страница документации, описывающая движок шаблонов werf.yaml.
Пофикшено именование пользовательских шаблонов. Имя шаблона — это относительный путь в директории .werf. {{ include “.werf/templates/1.tmpl” . }} => {{ include “templates/1.tmpl” . }}.
Определение безымянного образа в werf.yaml с помощью image: ~ не рекомендовано к использованию и будет удалено в v1.3. Лучше всегда выставлять явные имена образам, даже если образ один.
Функция env "ENVIRONMENT_VARIABLE_NAME" теперь требует наличия переменной ENVIRONMENT_VARIABLE_NAME (переменная может содержать пустое значение, но она должна быть явно определена).
Новая функция required даёт разработчикам возможность определить значение, которое требуется для рендера конфига. Если это значение пустое, то рендер сообщит об ошибке с помощью текста указанного в директиве required:
```
 {{ required "A valid <anything> value required!" <anything> }}
```

Стратегия тегирования

Доступна только стратегия тегирования на основе контента.
Возможность экспорта собранных образов в произвольный container registry будет добавлено позже.
Принудительное использование произвольных тегов для собранных образов будет добавлено позже.

Очистка

Очистка на основе истории git по умолчанию.
- В v1.1 такой режим работы включался опцией --git-history-based-cleanup-v1.2 (в v1.2 опция удалена).
Полностью удалены алгоритмы очистки на основе различных стратегий тегирования.
Опция --keep-stages-built-within-last-n-hours для сохранения образов, которые были собраны в указанный период до текущего момента (по умолчанию 2 часа).
Улучшения алгоритма очистки на основе истории git:
- Политика сохранения образов по директиве imagesPerReference.last учитывает, что может существовать несколько стадий образа, основанных на одном и том же коммите. Эти образы сохраняются и засчитываются как один для директивы imagesPerReference.last. Другими словами: imagesPerReference.last — это про количество коммитом, для одного коммита может существовать несколько образов.

Кеширование импортов из artifact/image по контрольной сумме

Представим, что имеется артефакт, который собирает некоторые файлы.
Данный артефакт имеет stage-dependency в werf.yaml для пересборки этих файлов, когда исходные зависимые файлы поменялись.
При очередном изменении исходных файлов вызывает пересборку артефакта.
- Т.к. изменился stage-dependency, то последняя стадия артефакта будет иметь другой дайджест.
- Однако после пересборки артефакта фактическая контрольная сумма файлов, которые были собраны не поменялась — получились точно такие же файлы.
  - В версии v1.1 werf всё равно выполнит переимпорт этих файлов в целевой образ.
    - Как последствие целевой образ будет пересобран и перевыкачен.
  - В версии v1.2 werf проверит контрольную сумму файлов, которые импортятся и перевыполнит импорт только при изменении этой контрольной суммы.

Поддержка первичного и вторичного хранилища образов

Автоматическая загрузка собранных локально образов в указанный container registry в --repo.
Использование стадий из read-only вторичного хранилища указанного опциями --secondary-repo (опция может быть указана несколько раз).
- Подходящие стадии из вторичного хранилища --secondary-repo будут скопированы в первичное хранилище --repo.

Built images report format changes

Команды werf converge, werf build, werf run, werf bundle publish и werf render имеют опции --save-build-report и --build-report-path. --save-build-report включает генерацию в следующем формате:

$ werf build --save-build-report

{
  "Images": {
    "result": {
      "WerfImageName": "result",
      "DockerRepo": "quickstart-application",
      "DockerTag": "32e88a6a19a425c9254374ee2899b365876de31ac7d6857b523696a1-1613371915843",
      "DockerImageID": "sha256:fa6445196bc8ed44e4d2842eeb068aab4e627112d504334f2e56d235993ba4f0",
      "DockerImageName": "quickstart-application:32e88a6a19a425c9254374ee2899b365876de31ac7d6857b523696a1-1613371915843"
    },
    "vote": {
      "WerfImageName": "vote",
      "DockerRepo": "quickstart-application",
      "DockerTag": "45f03bdd90c844eb2e61e7e01dae491588d2bdadbd195881b25be9b0-1613371915351",
      "DockerImageID": "sha256:a6845bbc7912e45c601b0291170f9f503722efceb9e3cc98a5701ea4d26b017e",
      "DockerImageName": "quickstart-application:45f03bdd90c844eb2e61e7e01dae491588d2bdadbd195881b25be9b0-1613371915351"
    },
    "worker": {
      "WerfImageName": "worker",
      "DockerRepo": "quickstart-application",
      "DockerTag": "1b16118e7d5c67aa3c61fc0f8d49b3eccf8f72810f01c33a40290418-1613371916044",
      "DockerImageID": "sha256:546af94bd73dc20a7ab1f49562f42c547ee388fb75cf480eae9fde02b48ad6ad",
      "DockerImageName": "quickstart-application:1b16118e7d5c67aa3c61fc0f8d49b3eccf8f72810f01c33a40290418-1613371916044"
    }
  }
}

или

$ werf build --save-build-report --build-report-path=.werf-build-report.env

WERF_RESULT_DOCKER_IMAGE_NAME=quickstart-application:32e88a6a19a425c9254374ee2899b365876de31ac7d6857b523696a1-1613371915843
WERF_WORKER_DOCKER_IMAGE_NAME=quickstart-application:1b16118e7d5c67aa3c61fc0f8d49b3eccf8f72810f01c33a40290418-1613371916044
WERF_VOTE_DOCKER_IMAGE_NAME=quickstart-application:45f03bdd90c844eb2e61e7e01dae491588d2bdadbd195881b25be9b0-1613371915351

Поддержка нескольких werf.yaml в одном git репозитории проекта

Пользователь может создать несколько werf.yaml (и .helm соответственно) в одном git репозитории проекта.

Все относительные пути в werf.yaml будут рассчитаны относительно текущей рабочей директории процесса werf или параметра --dir.
Обычно пользователь запускает werf прямо из директории, в которой расположен werf.yaml.
Также существует опция --config для передачи кастомного werf.yaml, все относительные пути в таком случае также будут рассчитаны относительно текущей рабочей директории процесса werf или параметра --dir.
Добавлен параметр --git-work-tree (и переменная WERF_GIT_WORK_TREE) для указания директории, которая содержит .git для случая, когда автодетектор этой директории не смог её найти, или когда мы хотим явно указать другую рабочую директорию git проекта.
- Например когда werf запускается из сабмодуля пользователь может захотеть использовать корневой git репозиторий проекта вместо git репозитория сабмодуля.
  - Чтобы сборочный кеш был связан с коммитами в главном репозитории.

Разное и внутренности

Добавлен кеш git-архивов и git-патчей в ~/.werf/local_cache/ по аналогии с уже существующем кешом git-worktree. Патчи и архивы более не создаются в /tmp/ (и --tmp-dir соответственно).
Удалена блокировка stages_and_images во время сборочного процесса.
- stages_and_images — это вспомогательная блокировка, которая ранее предотвращала одновременный запуск werf cleanup и werf build.
- В текущей версии данная блокировка может быть проигнорирована без последствий.
- Данная блокировка создаёт излишнюю нагрузку на сервер синхронизации, потому что она активна во время всего процесса сборки.
Также удалена неиспользуемая более блокировка image (legacy из v1.1).
Также переименованы блокировки связанные с использованием kubernetes в качестве lock-storage (сделано для большей корректности, несовместимое с v1.1 изменение).

Переработка документации

Вся документация разделена на секции по глубине погружения:
- главная страница;
- введение;
- быстрый старт;
- гайды/руководства;
- справочник;
- документация продвинутого уровня;
- внутренности.
Новая секция с руководствами.