我试图编写一个使用groovy.sql.SQL的全局函数脚本。
添加注释<PackageTargetFallback Condition=" '$(TargetFramework)' == 'netcoreapp1.1' ">$(PackageTargetFallback);dotnet5.6;portable-net45+win8</PackageTargetFallback>
时，在Jenkinsfile中使用全局函数时会出现异常。
以下是例外：
@GrabConfig(systemClassLoader=true)这是我的代码：
hudson.remoting.ProxyException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during conversion: No suitable ClassLoader found for grab
答案 0 :(得分：4)
确保＆＃34;使用groovy沙箱＆＃34;复选框未选中（它位于管道脚本文本框下方）。
答案 1 :(得分：1)
正如here所述，Pipeline＆＃34;脚本＆＃34;不是简单的Groovy脚本，它们在运行之前经过了大量的转换，主机上的某些部分，从机上的某些部分，其状态（变量值）被序列化并传递到下一步。因此，并非每个Groovy功能都受支持。
我不确定@Grab支持。它在JENKINS-26192中进行了讨论（声明为已解决，因此可能现在可以使用）。
摘自一个非常有趣的comment：
如果您需要执行一些复杂或昂贵的任务 不受限制的Groovy在物理上运行在奴隶上，它可能是最简单的 并且最简单地将该代码写入* .groovy文件中 您的工作区（例如，在SCM结帐中），然后使用工具和 sh / bat将Groovy作为外部进程运行;甚至把这些东西 进入Gradle脚本，Groovy Maven插件执行等工作流程 脚本本身应该限于简单和极轻量级 逻辑运算侧重于协调整体流程 控制和与其他Jenkins功能 - 奴隶分配交互， 用户输入等。
简而言之，如果您可以将需要SQL的自定义部件移动到外部脚本并在单独的进程中执行（从管道脚本调用），那应该可行。但是在Pipeline脚本中执行此操作会更复杂。