我正在尝试从管道步骤中运行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 回答
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 patternjobDsl(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'))
的操作