github - Jenkins 管道作业-DSL

Question

我正在尝试从管道步骤中运行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)
  }
}

运行此管道时，詹金斯会抱怨

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回购以普通代码包含共享库/作业构建器
1 Repo包含多个.Net解决方案，并且在根目录中包含Jenkinsfile


共享库回购已在Manage Jenkins-> Configure System中添加为全局管道库，并为每个管道隐式加载（例如Jenkinsfile）

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

#!/usr/bin/env groovy

dotNetStandardPipeline {
  message = "Hello World!"
}

由于全局管道库是隐式导入的，因此这就像魅力。现在，该dotNetStandardPipeline包含上述步骤，尝试调用jobDsl管道步骤，并将目标设置为DotNetJob.groovy脚本，该脚本位于与dotNetStandardPipeline本身相同的存储库中。
现在的问题似乎是，管道在“代码存储库”的工作空间中执行，因此路径“ src / breuer / jenkins / utils”不存在。

我如何知道脚本的真实位置，以及如何将jobDsl指定为目标，而目标本身又位于另一个存储库中？还是我可能在这里走错了路？

编辑

经过一些进一步的调查，事实似乎是，共享库存储库检出到带有@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)
}

不幸的是，这似乎完全破坏了某些东西，因为现在詹金斯会在构建的输出中抱怨以下消息：

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文件的位置，仍将无法调用它！

注意：将src目录直接复制到工作区中并将目标参数设置为src / breuer / jenkins ...等等时，它可以工作。

这是否意味着groovy脚本必须与jenkinsfile位于同一回购中？

编辑2

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

编辑3和结论

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

在此期间，我采用了另一种方法，我想向您介绍这一方法。
我已经在jenkins上使用了“ GitHub Organization”工作。目的是使它成为唯一手动创建的作业，并通过代码（即通过Jenkinsfile）创建所有其他所需的作业。
我需要注意的真正的存储库之一是一个从svn迁移到git的大量仓库，其中包含约300个.Net解决方案。这些解决方案中的每一个都应由詹金斯的个人工作来构建。我们可以在管道内部进行此操作，但这意味着以太在管道中有很多阶段，或者乍一看没有有关个别故障解决方案的信息。
因此，我必须为每个解决方案动态构建单独的作业。

代码仓库本身不应该被很多与詹金斯有关的东西所污染，因此我想严格区分这两件事。
现在，我不再使用管道调用job-dsl脚本，而是决定在jenkins中手动创建另一个Freestyle-Job。这用作种子作业，并具有一些参数（工作区，项目，分支等）。
现在，管道将触发种子作业的构建，然后使用所需的信息运行job-dsl。
在管道的此阶段完成之后，管道将随后触发所需作业的构建。

这可能不是最优雅的解决方案，但是通过这种方法，我实现了一个完全自动化的，在code jenkins环境中定义的环境，其中只有两个手动创建的作业。

Answer 1

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'))之类的操作。