首页 文章

Jenkins管道工作-dsl

提问于
浏览
3

我正在尝试从管道步骤中运行job-dsl脚本 . 通常,这应该是可能的,如here所述,在添加管道步骤中的代码片段之后:

stage('Add new jobs') {
  steps {
    echo 'Scanning...'
    jobDsl(additionalClasspath: 'src/breuer/jenkins/utils', removedJobAction: 'DELETE', removedViewAction: 'DELETE',
       targets: 'src/breuer/jenkins/utils/DotNetJob.groovy', unstableOnDeprecation: true)
  }
}

在运行此管道时,Jenkins会抱怨

ERROR: no Job DSL script(s) found at src/breuer/jenkins/utils/DotNetJob.groovy
Finished: FAILURE

DotNetJob.groovy的内容如下所示,用于测试目的:

#!/usr/bin/env groovy
package breuer.jenkins.utils

import javaposse.jobdsl.dsl.Job

def solutions = findFiles glob: '**/*.sln'
echo "Solution count: ${solutions.size()}"

job("TestDotNet") {
  steps {
    shell 'echo Hello from new DotNet job'
  }
}

我认为,问题是,管道作业和包含作业dsl的脚本位于不同的工作空间中 . 设置如下:

  • 1 GitHub组织

  • 2该组织内的存储库

  • 1 Repo包含groovy代码中的共享库/作业构建器

  • 1 Repo包含多个.Net解决方案,并在根目录中包含Jenkinsfile

共享库repo已在 Manage Jenkins -> Configure System 中添加为 global pipeline library ,并且为每个管道(例如Jenkins文件)进行了隐式加载

现在实际代码库中的管道非常小 . 它只是转发到共享库中的管道定义:

#!/usr/bin/env groovy

dotNetStandardPipeline {
  message = "Hello World!"
}

这就像魅力一样,因为全局管道库被隐含地导入 . 此 dotNetStandardPipeline 现在包含上述步骤,尝试调用 jobDsl 管道步骤,目标设置为 DotNetJob.groovy 脚本,位于与 dotNetStandardPipeline 本身相同的仓库中 .
现在的问题似乎是,管道在'Code-Repository'的工作空间中执行,因此路径'src/breuer/jenkins/utils'不存在 .

我如何知道脚本的真实位置?如何将jobDsl指定为目标,它本身位于不同的仓库中?或者我可能在这里完全错误的轨道?

EDIT

经过一些进一步的调查后,似乎事实是,共享库存储库被检出到"real"工作区旁边的目录,后面带有 @libs . 所以我认为使用以下方法是个好主意:

script {
    def wsName = "${WORKSPACE}".split("\\\\")[ -1 ]
    echo "wsName: ${wsName}"
    echo "RelDir: ../${wsName}@libs/breuer-jenkins-lib/src/breuer/jenkins/utils/DotNetJob.groovy"
    jobDsl(removedJobAction: 'DELETE', removedViewAction: 'DELETE',
                    targets: "../${wsName}@libs/breuer-jenkins-lib/src/breuer/jenkins/utils/DotNetJob.groovy", unstableOnDeprecation: true)
}

不幸的是,这似乎完全破坏了一些东西,因为现在jenkins会在构建的输出中抱怨以下消息:

java.nio.file.AccessDeniedException: D:\Road to Git\Jenkins\JenkinsGit\workspace\t_TestCIIntegration_develop-RKLAJXSET2S232SE6RNISESVW75KUNU4E3CPSAAP42MHZAGO6Z2A\.git
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(Unknown Source)
at java.nio.file.Files.newByteChannel(Unknown Source)
at java.nio.file.Files.newByteChannel(Unknown Source)
at java.nio.file.spi.FileSystemProvider.newInputStream(Unknown Source)
at java.nio.file.Files.newInputStream(Unknown Source)
at hudson.FilePath.read(FilePath.java:1771)
at hudson.FilePath$read$8.call(Unknown Source)
at javaposse.jobdsl.plugin.ScriptRequestGenerator.readFile(ScriptRequestGenerator.groovy:103)

所以看来,即使我能够确定groovy文件的位置,仍然无法调用它?!

note: 将src目录直接复制到工作区并将目标参数设置为src / breuer / jenkins ......等等,它可以正常工作 .

这是不是意味着,groovy脚本 has 与jenkinsfile在同一个回购中?

Edit 2

由于用文字解释我的计划背后的结构和想法是非常棘手的,我在GitHub上创建了一个带有两个演示存储库的小型演示组织 . here您可以找到包含两个C#解决方案和jenkinsfile的源代码库 . 自述文件描述了CI集成的计划 .
包含groovy脚本的CI库位于here

Edit 3 and Conclusion

对于大多数来这里的人,请检查mkobit给出的接受答案(感谢您的努力!) . 特别是解决实际问题的方法确实很有帮助 . 将job-dsl脚本放入资源中绝对是一种选择 .

与此同时,我采用了另一种方法,我想告知这一点 .
我已经在jenkins上使用"GitHub Organization"工作了 . 目的是让这是唯一的手动创建的作业,并通过代码(即通过Jenkins文件)创建所有其他所需的作业 .
我必须关注的一个真正的存储库是一个大量增长的回购,从svn转移到包含大约300个.Net解决方案的git . 这些解决方案中的每一个都应该由詹金斯的个人工作 Build . 我们可以在管道本身内做到这一点,但这意味着以太网在管道中有很多阶段,或者乍看之下没有关于单独失败解决方案的信息 . 因此,我必须为每个解决方案动态构建单个作业 .

代码回购本身不应该被很多jenkins相关的东西污染,所以我想严格区分这两件事 .
现在我没有让管道调用job-dsl脚本,而是决定在jenkins中手动创建另一个Freestyle-Job . 这用作Seed-Job并具有一些参数(工作空间,项目,分支等) .
现在,管道将触发种子作业的构建,然后使用所需信息运行job-dsl .
在管道中的这个阶段完成之后,管道将在之后触发所需作业的构建 .

这可能不是最优雅的解决方案,但通过这种方法,我只需要两个手动创建的作业即可在代码jenkins环境中实现完全自动化的定义 .

1 回答

  • 2

    GitHub Branch Source插件完成了一些事情:

    • 扫描一个或多个GitHub组织

    • 为每个存储库生成文件夹作业

    • 每个文件夹都会扫描具有 Jenkinsfile (默认配置)的重要事物(拉取请求,分支等)

    • 每个值得注意的东西都有为它生成的管道作业

    • 每个管道作业都可以自动通知GitHub构建状态(比如拉动请求)

    • 我确信我错过了其他值得注意的功能

    它可以通过轮询或通过监听事件来操作,例如拉取请求创建,拉取请求更新,分支和其他SCM事件 .

    我认为让 Jenkinsfile 为每个存储库生成带有 jobDsl 步骤的作业的想法可能过于复杂(当然取决于您期望的最终目标) . Jenkins Pipelines的一个好处是能够将构建定义指定为代码 . 在此示例中,您将定义用于构建项目的其他作业 . 为什么不让Jenkinsfile本身构建存储库,在全局库的帮助下定义公共路径?您已经有了GitHub Branch Source插件提供的作业生成和扫描,所以让 Jenkinsfile 完成构建过程的艰苦工作 .

    好吧,如果这不是令人信服或我不完全理解你的用例,让我们尝试解决你遇到的问题 .


    您需要在方法中考虑一些不同的考虑因素和限制

    jobDsl 步骤可以通过几种不同的方式提供作业脚本:

    • jobDsl(targets: 'ant/pattern/for/job/files/*.groovy') - 从工作区提供文件,目标可以是Ant pattern

    • jobDsl(scriptText: "folder('myFolder')") - 直接提供脚本文本

    Additional classpath选项要求文件也在工作区中 . 它还有一个额外的要求,即文件是在JVM类路径上工作的类文件/ JAR /事物 . 这意味着您必须在将工件与Job DSL一起使用之前组装这些工件,这将很难进入使用您的库的作业 .

    共享库是从源代码加载的,然后Jenkins Pipelines使用它的特殊编译器来准备执行 .

    我可以从这些选项中想到一些不同的选项和细节:

    • 不要在全局库中使用 additionalClasspath - 因为它需要构建类(本质上),您必须编译助手类

    • 使用 jobDsl(scriptText: '<JOB_DSL_TEXT_DIRECTLY>') - 您失去了一些仅测试Job DSL代码的能力,但您仍然可以进行集成样式测试以查看创建的作业 . (插入传入)我构建了一个Gradle plugin that allows you to test shared libraries,这样可能有助于测试方面 .

    • 如果要将Job DSL Groovy脚本分开,可能必须将其放在共享库的 resources 目录中,并仍然使用 scriptText 选项 . 例如,如果脚本位于 resources/breuer/jenkins/utils/DotNetJob.groovy 并且您的共享库已加载,则可以执行类似 jobDsl(scriptText: libraryResource('resources/breuer/jenkins/utils/DotNetJob.groovy')) 的操作

相关问题