问题标签 [delivery-pipeline]

我正在尝试使用 Jenkins 构建上述“交付管道”。

当上游作业成功结束时，除“手动步骤”之外的每个作业都将运行。我的问题是我无法在两个作业之间进行“加入”（并行运行“手动步骤”和“自动步骤”并等待 2 在“最后一步”之前成功完成）。詹金斯有什么办法可以做到这一点？也许一些插件？

这个问题与这个问题非常相似：如何在多个同时上游作业成功后让 Jenkins 作业开始？

但我真正想知道是否可以并行化两种不同类型的作业（手动运行的作业和自动运行的作业）。

我试图了解Delivery Pipeline与Active Deploy.

从不同的文档中，我可以理解Active Deploy可以部署零停机时间并支持回滚。

我很想知道Delivery Pipeline.

在 Bluemix 中，我必须在不同的区域（英国和美国南部）部署完全相同的应用程序。有没有一种方法可以使用交付管道的单个实例来部署到每个区域的不同空间。感谢帮助

我尝试在 jenkins Delivery Pipeline View 中显示一些交付管道实例。

如果交付管道实例被定义为“Free Style”或“MultiJob Project”，一切正常，但是当定义为“管道”时，作业不会出现在交付管道视图中。

我尝试了以下操作： my_pipeline-job 作为 Post-Build-action -> 构建其他项目（手动步骤）->Downstream Project Names->my_pipeline_job 结果是错误消息：无法构建 my_pipeline_job！

当我尝试将其构建为： my_pipeline-job as Post-Build-action -> 在其他项目上触发参数化构建 -> 构建触发器 -> 要构建的项目 -> my_pipeline_job 时消息消失但结果不会显示在交付管道中看法。

使用交付管道服务，我想将我的工件部署到暂存/QA 环境中，QA/产品团队成员可以在这些更改合并到生产分支之前测试功能/缺陷修复。

创建拉取请求时，我将如何启动这些临时测试环境？

我想添加自定义扩展，例如用于代码覆盖率的伊斯坦布尔、用于静态代码分析的 SonarQube、用于技术债务计算的自定义工具。是否可以向 Bluemix Delivery Pipeline 实例添加自定义扩展？

设置

• 我们正在使用 Jenkins 交付管道插件 ( https://wiki.jenkins-ci.org/display/JENKINS/Delivery+Pipeline+Plugin )
• 我们也在使用 Job DSL 插件 ( https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin )

如何通过 UI 进行操作

在视图配置页面上，视图中最后显示的作业有一个设置：

当给出最终作业时，视图不会显示任何可能由该作业触发的作业，即如标签所示，此作业是此视图中显示的最后一个作业。

问题

如何使用 Job DSL 配置此最终作业名称？

我们在 Jenkins 中使用“交付管道”插件。我们定义了一个名为“ DeliveryPipeline ”的视图。该视图将一个名为“ Initialize ”的作业作为其初始作业。

它显示了初始作业的内部版本号，如下图所示，这是正常作业的默认行为：

因此，当我单击任何内部版本号时；比如说 38，它会打开以下页面：

但是，期望的是，在初始作业“初始化”中单击内部版本号（此处为 38），应显示以下页面（这是构建 38 的管道视图）：

我们怎样才能做到这一点？

我正在使用交付管道插件将我的作业分组到多个阶段。目前，似乎没有机制可以直接转到视图中的特定旧管道实例。我想在管道的初始作业（ JobI ）中提供一种机制（可能是链接），以便每当我单击JobI的特定构建时，它应该将我直接重定向到管道视图的特定管道实例. 我还尝试通过其他一些管道插件（即构建管道等）来实现上述行为，但没有解决方案。这个想法是使视图易于用户使用，这样他就不必费心滚动浏览所有实例以到达特定实例。

我想为“视图的版本”或类似的复制“在作业中构建”的行为。

任何帮助/建议都会很棒。

这不是一个编程问题，而是一个交付管道问题：

我们的产品由几个 maven 工件构建而成，它们每天发布 SNAPSHOTS (2.0.1-SNAPSHOT)，每周发布版本 (2.0.1)。在开发过程中，我们的工件使用其他工件的快照进行了全面测试，并且一切正常。在许多情况下，工件是同时开发的，因此相互依赖而没有向后兼容性

管道的最后阶段使用其他工件的发布版本测试特定工件的发布候选，所以我正在尝试发布工件 A 的 2.0.1，它使用工件 B 的 2.3.5-SNAPSHOT 测试并通过. 如果通过，工件 A 被释放（2.0.1-SNAPSHOT 变为 2.0.1）

这是死胡同，因为工件 B 还没有发布 2.3.5（它会在几个小时内发布）。所以很明显，工件 A 在这个阶段会失败，因为它正在针对工件 B 的 2.3.4（这是 B 的最新版本）进行测试。

让我们假设所有工件都有相同的管道。

简单总结一下： Artifact A is at 2.0.1-SNAPSHOT attempting to release 2.0.1, its latest release is 2.0.0 Artifact B is at 2.5.2-SNAPSHOT attempting to release 2.5.2, its latest release is 2.5.1

stage 0 test -> A 2.0.0 with B 2.5.1 - PASSED

stage 1 test -> A 2.0.1-SNAPSHOT with B 2.5.2-SNAPSHOT - PASSED

stage 2 test -> A 2.0.1-SNAPSHOT with B 2.5.1- FAILED

我知道在 B 版本 2.5.2 之前它将继续失败，但我如何在我的交付管道中考虑到这一点。我希望工件 A 能够每周发布。

我正在寻找的是修复我的交付管道中的这个漏洞。我需要在管道中进行另一个阶段吗？释放收集的快照的另一个快照？