由于一些公司的变化,我们被迫改用詹金斯作为CI工具。虽然这似乎不是一个坏主意,但由于缺乏对非Java应用程序的支持,尤其是对管道(旧的工作流)插件的支持,以及我们对Jenkins知识的缺乏(目前还没有),我们遇到了很多麻烦。
node('master')
{
try
{
stage('Checkout, restore, build')
{
//Checkout the code from the repository
git branch: '<branch_name>', credentialsId: '<credentials_ID>', url: '<repo_URL>'
//git clean
bat returnStatus: true, script: 'git clean -fdx'
//Perform dotnet restore and nuget restore
bat returnStatus: true, script: '''for /f "tokens=*" %%a in (\'dir project.json /b /s\') do dotnet restore "%%a"
"C:\\Users\\Administrator\\.jenkins\\workspace\\nuget.exe" restore "C:\\Users\\Administrator\\.jenkins\\workspace\\CI\\<solution_name>.sln"'''
//Build the solution
bat returnStatus: true, script: '"C:\\Program Files (x86)\\MSBuild\\14.0\\Bin\\msbuild.exe" /p:DebugType=full /p:platform=x64 /p:configuration=release /p:VisualStudioVersion=14.0 '
}
} catch(err)
{
currentBuild.result = 'FAILURE'
}
jobDsl("${env.JOB_NAME}") {
steps {
bat returnStatus: true, script: '"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\CommonExtensions\\Microsoft\\TestWindow\\vstest.console.exe" "C:\\Users\\Administrator\\.jenkins\\workspace\\CI\\<path_to_tests_dll>" /TestCaseFilter:"TestCategory=UnitTest|TestCategory=ContinuousTest" /EnableCodeCoverage /Platform:x64 /logger:trx'
}
publishers {
archiveXUnit {
msTest {
pattern('"C:\\Users\\Administrator\\.jenkins\\workspace\\CI\\TestResults"')
}
}
}
}
}
但是jobdsl
出现错误:
java.lang.IllegalArgumentException:预期的命名参数,但在org.jenkinsci.plugins.workflow.cps.cps.dsl.parseargs(dsl.java:442)在org.jenkinsci.plugins.workflow.cps.dsl.invokeMethod(dsl.java:251)在org.jenkinsci.plugins.workflow.cpsscript.invokeMethod(dsl.java:129)在.lang.groovyObject$invokeMethod.call(来源未知)在org.codehaus.groovy.runtime.callsite.callsite.defaultCall(callsitearray.java:48)在org.codehaus.groovy.runtime.callsite.abstractCallsite.call(AbstractCallsite.java:113),在org.kohsuke.groovy.sandbox.impl.checker$1.call(checker.java:151)在在org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.sandboxinter调用(SandboxInterceptor.java:115)ceptor.onMethodCall(sandboxinterceptor.java:103),org.kohsuke.groovy.sandbox.impl.checker$1.call(checker.java:149),org.kohsuke.groovy.sandbox.impl.checker.checkedCall(checker.java:146),com.cloudbees.groovy.cps.sandboxinvoker.methodCall(sandboxinvoker.java:16),workflowScript.run(workflowblock$continuationimpl.dispatchorarg(functioncallblock.java:109)在com.cloudbees.groovy.cps.impl.functioncallblock$continuationimpl.fixarg(functioncallblock.java:82)在sun.reflect.generatedmethodaccessor295.invoke(未知源)在sun.reflect.delegatingmethodaccessimpl.invoke(未知源)在java.lang.reflect.Method.invoke(未知源46)在com.cloudbees.groovy.cps.next.step(next.java:74)在com.cloudbees.groovy.cps.continuable.run0(continable.java:154)在org.jenkinsci.plugins.workflow.cps.sandboxcontinuable.access$001(SandboxContinuable.java:18)在org.jenkinsci.plugins.workflow.cps.sandboxContinuable.1.在runinSandbox(groovySandbox.java:108)在org.jenkinsci.plugins.workflow.cps.sandboxContinable.run0(SandboxContinable.java:30)在org.jenkinsci.plugins.workflow.cps.cpstthread.runnextChunk(cpsthread.java:165)在org.jenkinsci.plugins.workflow.cps.cpstthread.java:165)在在org.jenkinsci.plugins.workflow.cps.cpsthreadgroup$2.call(CpsThreadgroup.java:228)在org.jenkinsci.plugins.workflow.cps.cps.cpsvmExecutorService$2.调用(cpsvmExecutorService.java:64)在java.util.concurrent.futuretask.run(未知源)在hudson.remoting.singlelaneExecutorService$1.运行(singlelaneExecutorService.java:112)在在java.util.concurrent.ThreadPoolExecutor$worker.run(未知源)在java.lang.thread.run(未知源)
这真的让我觉得这不是一个好方法,所以有人能给我一点启示,指引我走上正确的道路吗?
您不能混合管道DSL和作业DSL。那是完全不同的事情。
XUnit插件从1.100版开始就内置了对流水线DSL的支持,详细信息请参见JENKINS-27240。因此,您不需要尝试在流水线脚本中嵌入作业DSL脚本。
问题内容: 我有一个不同阶段的管道。我希望当前作业检查上一个版本中经过了多少个阶段并将其记录在控制台中? 考虑这是我当前的管道 我想要一个时髦的脚本给我这样的东西 我的代码的目的是跟踪构建过程中不同阶段的成功与失败。有没有其他替代方法? 问题答案: 您绝对可以使用Pipeline REST API插件,对我来说,Jenkins 2.13 可以直接使用它。 通过解析结果JSON,您可以获得与您期望的
问题内容: 我有管道脚本(groovy),我尝试在其中使用if和else条件,但其行为异常。似乎总是返回false。 这是我的管道脚本示例(片段): 但是,即使值是1,在这里它总是求值为false。语法是否存在问题? 当我做上述变量的回声时,它打印得很好。 更新:这是我最小的詹金斯管道脚本,请帮忙 问题答案: 请记住,返回的变量是字符串而不是数字。在Groovy(包括Jenkins Groovy
问题内容: 我想在一个定义管道构建作业的框架中利用Jenkins 的现有Mailer插件。给定以下简单的失败脚本,我希望每个构建版本都会收到一封电子邮件。 构建的输出为: 如您所见,它确实记录了它在失败后立即执行管道的过程,但是没有生成电子邮件。 利用自由工作的其他自由式工作中的电子邮件,只是通过管道工作来调用。 这与Jenkins 2.2和mailer 1.17一起运行。 是否有其他机制可以用来
我试图设置jenkins管道使用gCloud,但我得到以下错误: /service-account-creds.json警告:无法在 /.config/gcloud/logs中设置日志文件,(错误:无法创建目录[/. config/gCloud/logs/2019.02.07]:权限被拒绝。 守则: Jenkins使用imagen Jenkins/Jenkins在容器中运行
问题内容: 如何从内部触发另一个作业的生成? 我假设这项工作是同一个github组织下的另一个存储库,该存储库已经有自己的Jenkins文件。 我也只想在分支名称为master时执行此操作,因为触发任何本地分支的下游构建都没有意义。 更新: 不过,执行时我还是报错 找不到名为some-downtream-job-name的参数化作业 我确定这项工作存在于jenkins中,并且与当前工作位于同一组织