Конфигурация trdl.yaml содержит инструкции, которые определяют окружение и набор команд, необходимый для сборки артефактов релиза.

При релизе trdl читает trdl.yaml из Git-тега и выполняет сборку:

  • Запускает контейнер на базе выбранного Docker-образа.
  • Монтирует исходный код Git-тега в директорию /git.
  • Выполняет сборочные инструкции в директории /git.
  • Сохраняет артефакты релиза из директории /result.

Организация артефактов релиза

После выполнения сборочных инструкций артефакты релиза должны быть в директории /result. Артефактам требуется определённая организация директорий для интеграции с trdl-клиентом, доставки на различные платформы и эффективной работы с исполняемыми файлами.

Артефакты релиза необходимо сохранять в соответствующие директории платформ, для доставки на которые они рассчитаны. Имя директории платформы определяется операционной системой и архитектурой <os>-<arch>. Если разделение на операционные системы и/или архитектуры не требуется, можно использовать зарезервированное имя any. Ниже — список поддерживаемых комбинаций, выстроенных по приоритету использования trdl-клиентом.

darwin-amd64
darwin-arm64
darwin-any
linux-amd64
linux-amd64
linux-any
windows-amd64
windows-any
any-any

Чтобы использовать основную функциональность trdl-клиента (к примеру, команду trdl use), необходимо сохранять исполняемые файлы в поддиректории bin.

В итоге для большинства проектов справедлива следующая структура директории /result после сборки:

result
├── ...
└── <os>-<arch>
    ├── bin
    │   ├── ...
    │   └── <release artifact>
    ├── ...
    └── <release artifact>

Здесь:

  • os — операционная система (darwin, linux, windows или any, если артефакты релиза не зависят от системы);
  • arch — архитектура (amd64, arm64 или any, если артефакты релиза не зависят от платформы);
  • release artifact — произвольный файл.

Пример

trdl.yaml

dockerImage: alpine:3.13.6@sha256:e15947432b813e8ffa90165da919953e2ce850bef511a0ad1287d7cb86de84b5
commands:
- ./build.sh {{ .Tag }} && cp -a release-build/{{ .Tag }}/* /result

build.sh

#!/bin/sh -e
VERSION=$1
if [ -z "$VERSION" ] ; then
    echo "Required version argument!" 1>&2
    echo 1>&2
    echo "Usage: $0 VERSION" 1>&2
    exit 1
fi
mkdir -p release-build/${VERSION}/any-any/bin
printf "echo ${VERSION}\n" > release-build/${VERSION}/any-any/bin/trdl-example.sh
mkdir -p release-build/${VERSION}/windows-any/bin
printf "@echo off\necho ${VERSION}\n" > release-build/${VERSION}/windows-any/bin/trdl-example.ps1

Использование сборочных секретов

Вы можете использовать секреты во время сборки, предварительно добавив их в хранилище секретов с помощью метода /configure/build/secrets. Секреты мотируются по пути /run/secrets/<id>, где id - это идентификатор секрета использованного при добавлении секрета в хранилище. Пример использования:

dockerImage: alpine:3.13.6@sha256:e15947432b813e8ffa90165da919953e2ce850bef511a0ad1287d7cb86de84b5
commands:
- AWS_SHARED_CREDENTIALS_FILE=/run/secrets/aws ./build.sh {{ .Tag }} && cp -a release-build/{{ .Tag }}/* /result

Директория /result после выполнения сборочных инструкций

result
├── any-any
│   └── bin
│       └── trdl-example.sh
└── windows-any
    └── bin
        └── trdl-example.ps1