Вот чего я пытаюсь достичь:
У меня есть проект с заданием по сборке бинарной версии. Для кросс-компиляции двоичного кода для каждой платформы требуется время, поэтому я хочу, чтобы сборка выпуска выполнялась только тогда, когда выпуск отмечен тегом, но я хочу, чтобы локально-нативная версия создавалась, а тесты запускались для каждой зарегистрированной версии.
Основываясь на демонстрации летной школы ... пока что моя конфигурация конвейера выглядит так:
resources:
- name: flight-school
type: git
source:
uri: https://github.com/nbering/flight-school
branch: master
- name: flight-school-version
type: semver
source:
driver: git
uri: https://github.com/nbering/flight-school
branch: master
file: version
jobs:
- name: test-app
plan:
- get: flight-school
trigger: true
- task: tests
file: flight-school/build.yml
- name: release-build
plan:
- aggregate:
- get: flight-school-version
trigger: true
- get: flight-school
passed: [test-app]
- task: release-build
file: flight-school/ci/release.yml
Это создает конвейер в веб-интерфейсе, который выглядит следующим образом:
Проблема в том, что когда я обновляю файл "release" в репозитории git, ресурс semver "flight-school-version" может проверять до ресурса git "flight-school", в результате чего сборка выпуска обрабатывается из git версия, присвоенная предыдущему заезду.
Мне нужен способ обойти это, чтобы сборка выпуска отображалась как отдельная задача, но срабатывала только при повышении версии.
Некоторые вещи, о которых я думал до сих пор
Создайте отдельный ресурс git с набором tag_filter, чтобы он запускался только тогда, когда тег semver был отправлен в master.
- Плюс: задания запускаются только при нажатии тега.
- Против: имеет ту же проблему с отключенным наследованием для тестов, что и в приведенном выше примере на основе semver.
Добавьте условную проверку для тега semver (или измените diff в файле), используя историю git в оформлении заказа как часть скрипта сборки
- Pro: В основном буду делать то, что хочу, без особых проблем с Concourse.
- Против: невозможно увидеть разницу в пользовательском интерфейсе, не прочитав вывод сборки.
- Против: Трудно скомпоновать другие задачи и типы ресурсов, чтобы что-то сделать с бинарной версией.
Запуск сборки выпуска вручную
- Плюс: просто настроить
- Против: требуется ручное вмешательство.
Используйте API для запуска приостановленного этапа сборки по завершении тестов при обнаружении изменения версии
- Против: не видел примеров, чтобы другие делали это, кажется действительно сложным.
Я не нашел способа запустить задачу, когда оба ресурса git и ресурса semver меняются.
Я ищу либо ответ для решения проблемы параллелизма в приведенном выше примере, либо альтернативный шаблон, который приведет к аналогичному рабочему процессу выпуска.
