Запуск задач при изменении Semver: запуск заданий или порядок

Вот чего я пытаюсь достичь:

У меня есть проект с заданием на сборку для бинарной версии. Бинарному файлу требуется некоторое время для кросс-компиляции для каждой платформы, поэтому я хочу выпускать сборку только тогда, когда релиз помечен, но я хочу, чтобы локальная версия собиралась и тесты выполнялись для каждой зарегистрированной версии.

Основываясь на демонстрации летной школы... моя конфигурация трубопровода выглядит так:

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 был передан мастеру

  • Pro: Задания выполняются только когда нажата метка
  • Con: Имеет ту же проблему с отключенным наследованием для тестов, что и приведенный выше пример на основе semver

Добавьте условную проверку для тега semver (или измените diff для файла), используя историю мерзавцев в извлечении как часть сценария сборки

  • Pro: Будет делать то, что я хочу, не слишком много борясь с Concourse
  • Con: не вижу разницу в пользовательском интерфейсе, фактически не читая вывод сборки
  • Con: Сложно составить с другими задачами и типами ресурсов, чтобы сделать что-то с бинарным выпуском

Вручную вызвать сборку релиза

  • Pro: Простота настройки
  • Против: требует ручного вмешательства.

Используйте API для запуска приостановленного шага сборки по завершении тестов при обнаружении изменения версии

  • Кон: Не видел примеров того, как другие делают это, кажется действительно сложным.

Я не нашел способа вызвать задачу, когда меняются и ресурс git, и ресурс semver.

Я ищу либо ответ для решения проблемы параллелизма в моем примере выше, либо альтернативный шаблон, который приведет к аналогичному рабочему процессу релиза.

Источник

2 ответа

Решение

Резюме

Вот то, что я придумал для решения, основываясь на предложениях из слабого канала Concourse CI.

Я добавил параллельный "релизный" трек, который фильтрует теги, похожие на версии с семантическим версионированием. Две дорожки совместно используют файлы конфигурации задач и сценарии сборки.

Фильтрация тегов

Ресурс git поддерживает tag_filter вариант. Из README:

tag_filter: Необязательно. Если указан, ресурс будет обнаруживать только коммиты, у которых есть тег, соответствующий выражению, выполненному для branch, Шаблоны совместимы с glob(7) (как, например, bash).

Я использовал простой шаблон глобуса, чтобы соответствовать моим тегам semver (например, v0.0.1):

v[0-9]*

Сначала я попробовал шаблон "extglob", точно соответствующий семантическим версиям, например так:

v+([0-9]).+([0-9]).+([0-9])?(\-+([-A-Za-z0-9.]))?(\++([-A-Za-z0-9.]))

Это не сработало, потому что ресурс git не использует extglob вариант оболочки.

Конечный результат - это ресурс, который выглядит так:

resource:
  - name: flight-school-release
    type: git
    source:
      uri: https://github.com/nbering/flight-school
      branch: master
      tag_filter: 'v[0-9]*'

Повторное использование определений задач

Следующей проблемой, с которой я столкнулся, было избегание переписывания файла определения теста для дорожки релиза. Я должен был бы сделать это, потому что все пути к файлам используют имя ресурса, и теперь у меня есть ресурс для выпуска и разработки. Мое решение состоит в том, чтобы переопределить ресурс с помощью опции в задаче get.

jobs:
  - name: test-app-release
    plan:
      - get: flight-school
        resource: flight-school-release
        trigger: true
      - task: tests
        file: flight-school/build.yml

Build.yml, приведенный выше, является стандартным примером из руководства по летной школе.

Собираем все вместе

Мой получившийся конвейер выглядит так:

Конкурсный конвейер с параллельными трассами

Моя полная конфигурация конвейера выглядит так:

resources:
  - name: flight-school-master
    type: git
    source:
      uri: https://github.com/nbering/flight-school
      branch: master

  - name: flight-school-release
    type: git
    source:
      uri: https://github.com/nbering/flight-school
      branch: master
      tag_filter: 'v[0-9]*'

jobs:
  - name: test-app-dev
    plan:
      - get: flight-school
        resource: flight-school-master
        trigger: true
      - task: tests
        file: flight-school/build.yml

  - name: test-app-release
    plan:
      - get: flight-school
        resource: flight-school-release
        trigger: true
      - task: tests
        file: flight-school/build.yml

  - name: build-release
    plan:
      - get: flight-school
        resource: flight-school-release
        trigger: true
        passed: [test-app-release]
      - task: release-build
        file: flight-school/ci/release.yml
Источник

На мой взгляд, вы должны вручную нажать на release-build кнопку, и пусть все остальное будет автоматизировано. Я предполагаю, что вы вручную увеличиваете номер своей версии, но, кажется, лучше перенести это ручное вмешательство в выпуск.

То, что я хотел бы сделать, это положить в конце release-build это наталкивает вашу минорную версию. Что-то вроде:

- put: flight-school-version
  params:
    bump: minor

Таким образом, вы всегда будете на правильной версии, как только вы выпустите 0.0.1Вы закончили с этим навсегда, вы можете только идти вперед.

Источник
Другие вопросы по тегам