摘要

Question

这就是我想要实现的目标：

我有一个项目，其中包含二进制版本的构建作业。二进制文件需要一段时间来为每个平台进行交叉编译，因此我只想在标记版本时发布构建版本，但我希望构建本地版本的版本并为每个签入版本运行测试。

基于飞行学校的演示...到目前为止，我的管道配置如下：

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

这会在Web UI中生成如下所示的管道：

问题是，当我更新git存储库中的“release”文件时，semver资源“flight-school-version”可以在git资源“flight-school”之前检查，导致发布版本被处理来自分配给之前签到的git版本。

我想要一种方法来解决这个问题，以便发布版本作为一个单独的任务显示，但只在版本被碰撞时触发。

到目前为止我想到的一些事情

创建一个单独的git资源，并设置tag_filter，以便仅在将semver标记推送到主控时运行

Pro：仅在按下标记时运行作业
Con：与上面基于semver的示例

使用结帐中的git历史记录作为构建脚本的一部分，为semver标记添加条件检查（或更改文件上的diff）

亲：如果不与Concourse进行过多的摔跤，基本上会做我想做的事。
Con：在没有实际阅读构建输出的情况下看不到UI的区别
Con：很难与其他任务和资源类型合并以使用二进制版本执行某些操作

手动触发发布版

Pro：设置简单
Con：需要手动干预。

在检测到版本更改时，使用API在测试完成时触发暂停的构建步骤

Con：没看过其他人这样做的例子，看起来真的很复杂。

当两者 git资源和semver资源发生变化时，我还没有找到触发任务的方法。

我正在寻找解决上述示例中的并发问题的答案，或者是一种可以产生类似发布工作流的替代模式。

Answer 1

摘要

根据Concourse CI松弛频道的建议，以下是我提出的解决方案。

我添加了一个并行的“发布”曲目，该曲目会过滤类似semantic versioning版本的标签。这两个轨道共享任务配置文件和构建脚本。

标记过滤

git资源支持tag_filter选项。来自自述文件：

tag_filter：可选。如果指定，资源将仅检测提交具有与已针对的表达式匹配的标记 branch。模式是glob(7) 兼容（如，兼容bash）。

我使用了一个简单的glob模式来匹配我的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 shell选项。

最终结果是一个如下所示的资源：

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是flight school教程中的标准示例。

全部放在一起

我生成的管道如下所示：

我的完整管道配置如下所示：

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

Answer 2

在我看来，您应该手动点击release-build按钮，让其他所有内容自动化。我假设你手动碰撞你的版本号，但似乎最好将手动干预移动到释放。

我要做的是放在release-build的末尾，这会使你的次要版本受到影响。类似的东西：

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

这样你将永远保持正确的版本，一旦释放0.0.1，你就永远完成了它，你只能前进。

触发Semver更改任务：触发作业或命令

到目前为止我想到的一些事情

2 个答案:

摘要

标记过滤

重新使用任务定义

全部放在一起