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)
  }
}

运行此管道时，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 Organization
该组织内的2个存储库
1 Repo包含groovy代码中的共享库/作业构建器
1 Repo包含几个.Net解决方案，根目录中有Jenkinsfile

共享库repo已添加为管理Jenkins - ＆gt;中的全局管道库配置系统并为每个管道（例如Jenkins文件）

进行隐式加载

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

#!/usr/bin/env groovy

dotNetStandardPipeline {
  message = "Hello World!"
}

这就像魅力一样，因为全局管道库被隐含地导入。此 dotNetStandardPipeline 现在包含上述步骤，尝试调用 jobDsl 管道步骤，目标设置为 DotNetJob.groovy 脚本，位于与 dotNetStandardPipeline 本身相同的回购现在的问题似乎是，管道是在“代码库”的工作区中执行的。因此路径＆s; src / breuer / jenkins / utils＆＃39;不存在。

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

修改

经过一些进一步的调查后，似乎事实上，共享库存储库被检出到＆＃34; real＆＃34;旁边的目录。带有 @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文件的位置，仍然无法调用它？！

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

这是否意味着，groovy脚本有与jenkinsfile在同一个repo中？

修改2

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

编辑3和结论

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

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

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

这可能不是最优雅的解决方案，但通过这种方法，我只需要两个手动创建的作业即可在代码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 /事物。这意味着您必须在将工件与工作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'))

Jenkins管道工作-dsl

1 个答案: