我正在尝试让詹金斯(Jenkins)的多分支管道工作来以类似于分支的方式构建标签。在Jenkins
2.73(不确定何时添加功能)中,可以将Multibranch项目配置为从源存储库中检索分支和标签。最初,我认为这将非常适合我的需求(我的Jenkinsfile现在可以在Jenkins的同一位置进行开发或生产构建)。
配置了标签发现的多分支作业
我已经使用脚本管道成功构建并运行了构建过程,但是我的问题是,尽管分支作业完美地捕获了触发器(每周Cron),因此可以使用Git插件的notifyOnCommit功能进行触发(允许我每周清理构建一次)
,但也可以通过回购扫描webhook在提交给回购的基础上进行构建),而标记构建则不会。
还有其他人遇到吗?如果是这样,您是否找到任何合理的解决方法?
我的脚本管道中的相关代码段(我尝试使用和不使用overrideIndexTriggers
设置): properties( [ pipelineTriggers( triggers: [ cron('H 02 * * 7') ] ), overrideIndexTriggers(true) ] )
从多分支管道生成的分支作业轮询配置似乎很好
,由多分支管道从标签生成的作业没有收到相同的配置,这很奇怪。
在多分支管道扫描日志中有一条注释表明,标记永远不会被自动调度: Processed 8 branches Checking tags... Checking tag testing ‘Jenkinsfile’ found Met criteria No automatic builds for testing Processed 1 tags [Mon Oct 23 09:55:00 UTC 2017] Finished branch indexing. Indexing took 8.1 sec Finished: SUCCESS
我的项目基于docker,我想每周运行一个发布版本,以获取任何基础映像更改等。
有谁对我可以做什么来使多分支项目计划标签构建有任何想法?
根据JENKINS-47496的说法,不是自动触发针对发现的标签的构建。斯蒂芬·康诺利(Stephen
Connolly)为您可能做的事情提供了解释和建议:
Stephen Connolly添加了评论-6天之前
默认情况下不会构建标签(因为否则可能会在签出存储库时产生构建风暴),更糟糕的是,内置的订单标签是不可预测的…并且当标签为时,您可能会有一个Jenkinsfile部署到生产环境中内置的。
branch-api中有一个称为BranchBuildStrategy的扩展点,如果实现,则可以决定是否构建标签。
有关如何创建此类扩展插件的起点,请参见https://github.com/jenkinsci/github-branch-source-
plugin/pull/158#issuecomment-332773194
…我相信在https上有一些工作://github.com/AngryBytes/jenkins-build-everything-
strategy-plugin
null null 我怎样才能想象这些工作类型之间的关系?还有其他插件支持这些类型吗?
对于一个新项目,我想使用Jenkins CI的新管道功能。我们的Git存储库中有几个分支,应该以同样的方式进行测试。它还应该自动跟踪和处理新的分支。因此,我创建了一个多分支管道作业。但它的配置有两个问题: 1) 为了被Jenkins标记为有效,分行需要一个“Jenkinsfile”。如果这不存在,詹金斯将忽略该分支。有没有办法标记与模式匹配的所有分支,而不需要在其中包含此文件? 2) 每个分支都应
我对使用Jenkins文件和GIT插件的Jenkins多分支pipleline有一个问题。 问题是,每次向暂存分支推送都会触发master管道。所需的行为是,推送到暂存分支仅触发用于暂存的管道,而推送到主分支仅触发主管道 这是我的詹金斯档案 我将分享一些日志:这是主分支的日志 这是主分支的日志,但只有暂存有一个新的提交: 注意“已发现更改”,即使主分支上的头未更改 詹金斯·弗。2.190.1 Gi
我正在努力使用Jenkins 2.1多分支管道,在这里,我从同一个git存储库构建了多个工件。一些工件是独立的,应该根据它们各自目录中的更改触发构建。有些是依赖的,应该由先前的步骤/构建触发。 存储库有一个控制整个管道的文件。Jenkins多分支管道作业会在所有更改时触发(无其他行为)。 我不知道如何在目录dirA发生变化时触发工件A的构建。 git回购协议中的Jenkins文件file:///r
我遇到了JENKINS-38706。由于它已经开放了一段时间,我正在努力解决这个问题。 我的问题是我正在运行一个多节点管道,其中一个节点是Windows从节点,具有255个字符路径限制。 因此,我正在尝试更改我的Windows从属阶段的工作区,而不是使用多分支管道使用的C:\jenkins\workspace\job-分支-随机字符,我正在尝试将其移动到c:\w\Jobs\分支。 它立即失效: 我
现在多分支管道作业类型已经成熟,还有什么理由再使用简单的管道作业类型吗?即使您现在只有一个分支,考虑到未来多个分支的可能性可能是明智的,那么假设您将Jenkins管道存储在SCM中,那么为您的Jenkins管道使用管道作业类型与始终使用多分支管道作业类型的动机是什么?现在这两种作业类型之间是否存在功能平价?