我们有一个由Github Action(在下面列出)触发的Jenkins工作。
name: CI
on:
pull_request:
branches:
- test/*
types: [ closed ]
jobs:
build:
if: github.event.pull_request.merged == true
name: Build
runs-on: ubuntu-latest
steps:
- name: trigger single Job
uses: appleboy/jenkins-action@master
with:
url: "https://example.company.com"
user: "appleboy"
token: ${{ secrets.TOKEN }}
job: "Pipeline"
该触发器现在被通配为以test/
开头的任何分支。但是,每次触发触发器时,Jenkins作业都会从错误的分支中进行构建。我注意到的是,每次发生这种情况时,我都需要在Jenkins UI中对分支进行硬编码,然后选择“立即构建”选项并手动运行它。当我将构建返回到通配符规范并再次触发时,这次是从新分支开始,它是从我先前手动输入的分支构建的。工作流程示例:
PR合并到分支test/v1
Jenkins作业已触发,但从先前手动输入的分支(即test/v0
)开始构建
我对分支进行硬编码并手动执行构建
PR合并到分支test/v2
Jenkins作业已触发,但从test/v1
分支开始构建
更新
通过从分支说明符中删除remotes
,我得到以下行为:
PR已合并到test/v2
Jenkins作业已触发,但从test/v1
同时触发从test/v2
构建的另一个作业
在步骤2的构建日志中,我看到以下消息(步骤3的构建中不存在此消息):
多个候选修订
计划另一个版本以赶上管道
答案 0 :(得分:1)
原来是以下链接中提到的问题。回购中有多个以origin/test/
开头的分支,从而导致了多个构建候选。只需删除这些分支即可解决问题。