当前位置: 首页 > 知识库问答 >
问题:

如何在Jenkins多分支管道作业中仅构建一个目录?

罗星洲
2023-03-14

我有一个名为multibranch test的github repo,它有两个子目录Project1和Project2。

PS C:\Repos\multi-branch测试

每个子目录都有一个Jenkinsfile和该项目的代码。

在Jenkins中,我有两个多分支管道作业——一个用于Project1,一个用于Project2。在Project1的配置中,如果在Project2的子目录中推送了提交,我不希望消息推送或轮询来构建Project1。

因此,在项目1中,我配置了其他行为:

  • 高级克隆行为:选中浅克隆
  • 稀疏签出路径设置为Project1#
  • 轮询忽略某些路径中的提交
    • 包括地区:项目1/*
    • 排除的区域:*

    发生的情况是,如果我在子目录Project2中推送提交到master,Project1和Project2作业都会被构建。我只希望构建Project2。有人能指出我做错了什么吗?

    两个项目的Jenkins文件相似,看起来像:

    #!groovy
    node  {
        stage ('checkout') {
            checkout scm
        }
    
        stage ('build') {
            dir ('Project1') {
                bat 'powershell -Command gci'
                bat 'powershell -Command gci env:'
                bat 'powershell -File .\\Project1.ps1'
            }
        }
    

共有3个答案

太叔俊侠
2023-03-14

您可以为整个repo创建一个job,它查看提交给您带来的更改,然后触发项目1或2的相应Jenkinsfile,或者两者都触发

许彭祖
2023-03-14

Jenkins的默认行为是,如果项目的repo收到提交,则项目会被重建,因此您在repo中的提交会为Jenkins项目生成事件并触发两个构建。查看Jenkins文档:https://jenkins.io/doc/book/pipeline/

从詹金斯的角度来看,很难判断项目1或项目2是否发生了变化——立即可见的是“新的回购promise”。

Simples的解决方案是将回购分为两个独立的回购,每个项目一个。既然他们应该分开建造,那就不成问题了。

李利
2023-03-14

这对我们来说是一个很大的麻烦,但我们通过一些变通办法解决了它。

我们有一个由GitHub提交挂钩触发的master Jenkins作业。它找出自上次提交以来发生的变化,然后触发其他特定于服务的Jenkins作业。

我们还使用了一些其他约定(如服务、目录和Jenkins作业的命名约定),这些约定在这里没有指定,但希望这能对其他人有所帮助。

以下是解决方案中每个组件的细分:

  1. monorepo中每个服务的Jenkins作业和相应的Jenkins文件

C:\REPOS\MULTIBRANCH-TEST\Project1\Jenkinsfile(您的构建逻辑在这里)C:\REPOS\MULTIBRANCH-TEST\Project2\Jenkinsfile(您的构建逻辑在这里)

<代码>C:\REPOS\MULTIBRANCH-TEST\change set。sh

    #!/usr/bin/env bash

    changeSets=(`git diff-tree --name-status HEAD`)
    for(( i=0; i<${#changeSets[@]}; i++))
    do
      if [ ${changeSets[$i]} == "M" ]
      then
        echo ${changeSets[$i+1]}
      fi
    done

C:\REPOS\MULTIBRANCH-TEST\Jenkinsfile

    #!/usr/bin/env groovy

    pipeline {
        agent any

        stages {

            stage('Define Services to Build') {
                steps {
                    script {

                        def SERVICES_TO_BUILD = sh script:"./change-sets.sh", returnStdout: true
                        SERVICES_TO_BUILD.split("\n").each {
                            echo "Triggering build for ${it}"
                            try {
                                build job: "${it}", propagate: false, wait: false
                            } catch (ex) {
                                echo "Failed to trigger build for ${it}: ${ex.message}"
                            }

                        }
                    }
                }
            }
        }
    }
 类似资料:
  • 是否有可能通过一个作业DSL创建多分支管道作业,该作业通过“管道脚本”而不是每个Git存储库包含的Jenkinsfile来定义作业? 我们希望避免在100个Git存储库中生成和维护相同的Jenkins文件(除了一些参数)。 目前,我们正在使用管道作业和工厂作业播种的作业DSL,但目前我们在多分支构建(功能分支)方面受到限制。因此,我们希望切换到多分支管道作业,但在播种方面我们受到了限制。 我知道我

  • 是否有人知道从文件中设置作业属性(特别是构建触发器)的正确方法?(多分支管道作业中的声明性管道脚本)。 为了清晰起见,我需要为多分支项目中的底层作业设置特定的构建触发器。我可以在GUI中配置总体多分支项目的触发器。 尝试过这里列出的方法:Jenkins多分支管道和指定上游项目 詹金斯:在上游更改时触发多分支管道 如何使用Jenkins管道属性步骤? 从v0开始,我就听到这样的错误。8我应该使用选项

  • 问题内容: 标题大多是这样说的。如何从远程git存储库触发Jenkins多分支管道项目构建? “ Trigger远程构建”构建触发器选项似乎不起作用,因为没有保存您设置的令牌。 问题答案: 目前(Jenkins 2.22),“触发触发器远程构建”构建触发选项在多分支管道作业配置中可见,但不起作用(如果您检查并指定了令牌,则无论如何保存后都会重置)。根据这个,这是故意的触发器不能确定,但一个错误,它

  • null null 我怎样才能想象这些工作类型之间的关系?还有其他插件支持这些类型吗?

  • 现在多分支管道作业类型已经成熟,还有什么理由再使用简单的管道作业类型吗?即使您现在只有一个分支,考虑到未来多个分支的可能性可能是明智的,那么假设您将Jenkins管道存储在SCM中,那么为您的Jenkins管道使用管道作业类型与始终使用多分支管道作业类型的动机是什么?现在这两种作业类型之间是否存在功能平价?

  • 问题内容: 我正在利用多分支管道工作流,在Jenkins中将并发构建的数量限制为特定数量,但是在docs或google中找不到任何好的方法。 一些文档说这可以在Jenkinsfile步骤中使用并发来完成,但是我在其他地方也读过,这是不推荐使用的方式。 似乎最近发布了一些用于限制并发通过的东西,但是我找不到它的文档,并且在遵循代码时遇到了麻烦。我唯一发现的PR显示以下内容: 但是我很难让它工作。 是