詹金斯管道作业-DSL

Question

我试图从流水线步骤中运行一个job-dsl脚本。一般来说，这应该是可能的，正如这里所描述的，在管道步骤中添加了以下代码片段：

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

#!/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'
  }
}

null

#!/usr/bin/env groovy

dotNetStandardPipeline {
  message = "Hello World!"
}

我如何知道脚本的真实位置，以及如何指定一个jobDsl作为目标，它本身位于不同的repo中？还是我完全走错了方向？

编辑

经过进一步的研究，共享库存储库被签出到“真实”工作区旁边的一个目录中，后缀为@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)

与此同时，我遵循了另一种方法，我想告诉你这一点。
我已经在Jenkins上使用了一个“GitHub Organization”工作。我们的目标是让这是唯一手工创建的作业，并通过代码（即通过Jenkinsfile）创建所有其他所需的作业。
我必须关心的真正的存储库之一是一个大量增长的repo，它从svn转移到git，其中包含大约300个.NET解决方案。这些解决方案中的每一个都应该由詹金斯的个人工作来构建。我们可以在管道本身内完成，但这将意味着管道中有很多阶段，或者乍一看没有关于单个失败解决方案的信息。因此，我必须动态地为每个解决方案构建单独的作业。

代码repo本身不应该被许多与jenkins相关的东西污染，所以我想严格地将这两件事分开。
现在，我决定在jenkins中手动创建一个Freestyle-Job而不是让管道调用job-dsl脚本。它充当种子作业，并具有一些参数(workspace、project、branch等）。
现在管道将触发种子作业的构建，然后种子作业使用所需的信息运行job-dsl。
完成管道中的这一阶段后，管道将触发所需作业的构建。

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

Answer 1

GitHub分支源代码插件实现了以下几点：

• 扫描一个或多个GitHub组织
• 为每个存储库生成文件夹作业
• 每个文件夹扫描具有JenkinsFile（默认配置）
的显著内容（请求、分支等）
• 每个值得注意的东西都有一个为它生成的管道作业
• 每个流水线作业都可以自动通知GitHub生成状态（例如在请求时）
• 我肯定错过了其他值得注意的功能

它可以通过轮询或侦听事件来操作，例如请求创建、请求更新、分支和其他SCM事件。

null

我可以从这些选项中想到几个不同的选项和细节：

1. 不要在全局库中使用additionalclasspath-因为它需要构建类（本质上），所以必须编译帮助器类
2. 使用jobdsl(scripttext:' ') -您失去了一些测试作业DSL代码的能力，但是您仍然可以进行集成样式测试来查看创建了哪些作业。（插件传入）我构建了一个Gradle插件，允许您测试共享库，因此这可能有助于测试方面。
3. 如果要单独保存作业DSL Groovy脚本，可能必须将其放在共享库中的resources目录中，并且仍然使用scripttext选项。例如，如果脚本位于resources/breuer/jenkins/utils/dotnetjob.groovy，并且已加载共享库，则可以执行以下操作：jobdsl(scripttext:libraryResource('resources/breuer/jenkins/utils/dotnetjob.groovy'))