Jenkinsfile-Jenkins构建用户getUserName()NullPointerException:无法在空对象上调用方法getUserName()Mutli Branch Indexing Scanning [英] Jenkinsfile - Jenkins build user getUserName() NullPointerException: Cannot invoke method getUserName() on null object Mutli Branch Indexing Scanning

查看：94
本文介绍了Jenkinsfile-Jenkins构建用户getUserName()NullPointerException:无法在空对象上调用方法getUserName()Mutli Branch Indexing Scanning的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

Jenkins 2.138.1.2-滚动-和-使用

要实现相同的功能，在我的 Jenkinsfile 中，我在顶部有以下代码:

  @NonCPSdef getBuildUser(){def build = currentBuild.rawBuilddef原因= build.getCause(hudson.model.Cause.UserIdCause.class)定义BUILD_USER = cause.getUserName()返回BUILD_USER}管道{...}

类定义:

每隔 10 分钟设置一次多分支扫描周期的设置.

我看到有时 build失败，并出现以下错误，即 java.lang.NullPointerException:无法在空对象上调用方法getUserName()等，则说明构建一直成功，并且对构建的描述也不错.

  [Bitbucket]生成结果已通知java.lang.NullPointerException:无法在空对象上调用方法getUserName()在org.codehaus.groovy.runtime.NullObject.invokeMethod(NullObject.java:91)在org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)在org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)在org.codehaus.groovy.runtime.callsite.NullCallSite.call(NullCallSite.java:35)在org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)在org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)在org.kohsuke.groovy.sandbox.impl.Checker $ 1.call(Checker.java:158)在org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:160)在org.kohsuke.groovy.sandbox.impl.Checker $ checkedCall $ 1.callStatic(未知来源)在org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)在org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)在WorkflowScript.getBuildUser(WorkflowScript:5)在sun.reflect.NativeMethodAccessorImpl.invoke0(本机方法)处在sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)在sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)在java.lang.reflect.Method.invoke(Method.java:498)在org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)在groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)在groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)在groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)在org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)在org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)在org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)在org.kohsuke.groovy.sandbox.impl.Checker $ 1.call(Checker.java:158)在org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)在org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:157)在org.kohsuke.groovy.sandbox.impl.Checker $ 1.call(Checker.java:156)在org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:160)在org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:125)在org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:130)在com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)在WorkflowScript.run(WorkflowScript:75)在___ cps.transform ___(本机方法)在com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)在com.cloudbees.groovy.cps.impl.FunctionCallBlock $ ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)在com.cloudbees.groovy.cps.impl.FunctionCallBlock $ ContinuationImpl.fixName(FunctionCallBlock.java:77)在sun.reflect.GeneratedMethodAccessor333.invoke(未知来源)在sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)在java.lang.reflect.Method.invoke(Method.java:498)在com.cloudbees.groovy.cps.impl.ContinuationPtr $ ContinuationImpl.receive(ContinuationPtr.java:72)在com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)在com.cloudbees.groovy.cps.Next.step(Next.java:83)在com.cloudbees.groovy.cps.Continuable $ 1.call(Continuable.java:174)在com.cloudbees.groovy.cps.Continuable $ 1.call(Continuable.java:163)在org.codehaus.groovy.runtime.GroovyCategorySupport $ ThreadCategoryInfo.use(GroovyCategorySupport.java:122)在org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261)在com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)在org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access $ 001(SandboxContinuable.java:18)在org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)在org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174)在org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:347)在org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access $ 200(CpsThreadGroup.java:93)在org.jenkinsci.plugins.workflow.cps.CpsThreadGroup $ 2.call(CpsThreadGroup.java:259)在org.jenkinsci.plugins.workflow.cps.CpsThreadGroup $ 2.call(CpsThreadGroup.java:247)在org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService $ 2.call(CpsVmExecutorService.java:64)在java.util.concurrent.FutureTask.run(FutureTask.java:266)在hudson.remoting.SingleLaneExecutorService $ 1.run(SingleLaneExecutorService.java:131)在jenkins.util.ContextResettingExecutorService $ 1.run(ContextResettingExecutorService.java:28)在jenkins.security.ImpersonatingExecutorService $ 1.run(ImpersonatingExecutorService.java:59)在java.util.concurrent.Executors $ RunnableAdapter.call(Executors.java:511)在java.util.concurrent.FutureTask.run(FutureTask.java:266)在java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)在java.util.concurrent.ThreadPoolExecutor $ Worker.run(ThreadPoolExecutor.java:617)在java.lang.Thread.run(Thread.java:745)完成:失败

我注意到，当 Multi-Branch Scanning / Branch Indexing 在后台运行时，仅会发生这种情况，因为失败的内部版本在该内部版本号的控制台页面中列出了以下内容.

要获得具有构建说明及所有内容的成功构建，请使用上述"分支索引"框不可见(针对成功的构建号).

为什么要得到这个 java.lang.NullPointerException:无法在空对象上调用方法getUserName()错误(在后台进行扫描时)--或如何避免构建失败?

PS :要重现此问题，用户只需点击
立即扫描多分支管道 的侧边栏图标/链接，这将导致构建失败并显示以下控制台输出:

PS :安装新插件可能需要安全团队花费一些时间(1-2周)/扫描/批准过程，所以我认为这不是一个选择，至少要等到批准通过.例如: https://plugins.jenkins.io/build-user-vars-plugin/

解决方案

为避免构建失败，目前，我启用了 try 和 catch 并为BUILD_USER设置了值 getCause(...)将会失败...当有人单击侧边栏链接时立即扫描MultiBranch管道，然后是控制台输出或Jenkins 不会设置单击该侧边链接上的的用户来启动构建(如果要进行任何更改)，并显示分支索引作为输出的第一行(而不是显示:由用户< some name>(someUserID)开头).

因此，以下内容会将BUILD_USER设置为有意义的值，并且不会使构建失败.

  @NonCPSdef getBuildUser(){def build = currentBuild.rawBuilddef BUILD_USER ="ToBeSet";尝试 {def原因= build.getCause(hudson.model.Cause.UserIdCause.class)BUILD_USER = cause.getUserName()} catch(Exception ex){println"\ n \ n-由多分支流水线扫描-或-计时器(即不是由登录用户直接产生的\ n"引起的构建)；BUILD_USER ="Multi_Branch_Scan_or_Timer"；}返回BUILD_USER}

我仍然想知道是否有办法找到并单击侧边栏链接(已登录用户)的人.

Jenkins 2.138.1.2-rolling --and-- using MultiBranch Pipeline (to build build from master, branches and Pull Requests etc).

I want to show Jenkins build job's user who initiated the build in build description.

Ex:

For implemennting the same, in my Jenkinsfile, I have the following code at the top:

@NonCPS
def getBuildUser() {
    def build = currentBuild.rawBuild
    def cause = build.getCause(hudson.model.Cause.UserIdCause.class)
    def BUILD_USER = cause.getUserName()
    
    return BUILD_USER
}

pipeline {
    ...
}

Class definition: https://javadoc.jenkins-ci.org/hudson/model/Cause.UserIdCause.html shows the method is NOT Deprecated (like it's in the case of UserCause class).

In Jenkinsfile, under the stages section, I have the following code, which is implementing this successfully.

stages {
   stage ('Start') {
       steps {
           script {
                   // Set Build Description
                   def BUILD_USER= getBuildUser()
                   currentBuild.description = "${BUILD_USER}: ${RELEASE_TAG} => ${DOCKER_IMAGES}"
           }

           sh '''
                 set +x
                 echo -e "\n\n-- Starting build process.\n"
              '''
       }
   }
   .. more stages are here ..
 }

As I'm using Multi-Branch Pipeline job, I see all the branches/PR including master and on the side bar, I see the following links:

The setting for multi-branch scan period is set for every 10 minutes.

I'm seeing that sometimes the build is FAILING with the following error i.e. java.lang.NullPointerException: Cannot invoke method getUserName() on null object and other times, the build is successful all the way and build description is also good.

[Bitbucket] Build result notified
java.lang.NullPointerException: Cannot invoke method getUserName() on null object
    at org.codehaus.groovy.runtime.NullObject.invokeMethod(NullObject.java:91)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.NullCallSite.call(NullCallSite.java:35)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:158)
    at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:160)
    at org.kohsuke.groovy.sandbox.impl.Checker$checkedCall$1.callStatic(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
    at WorkflowScript.getBuildUser(WorkflowScript:5)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
    at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
    at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:158)
    at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
    at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:157)
    at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:156)
    at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:160)
    at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:125)
    at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:130)
    at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
    at WorkflowScript.run(WorkflowScript:75)
    at ___cps.transform___(Native Method)
    at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixName(FunctionCallBlock.java:77)
    at sun.reflect.GeneratedMethodAccessor333.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
    at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
    at com.cloudbees.groovy.cps.Next.step(Next.java:83)
    at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
    at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
    at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122)
    at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261)
    at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
    at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:51)
    at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:347)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:93)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:259)
    at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:247)
    at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131)
    at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
    at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Finished: FAILURE

I noticed, that this is happening ONLY when Multi-Branch Scanning / Branch Indexing is running in the background because, as all the failed builds have the following getting listed in that build number's console page.

For successful builds with build description and all, the above "BRANCH INDEXING" box is not visible (against that successful build #).

Why I'm getting this java.lang.NullPointerException: Cannot invoke method getUserName() on null object error (when Scanning is in progress in the background) --or what can I do to avoid the build failure?

PS: To recreate this issue, a user can simply just click on the
sidebar icon/link for Scan Multibranch Pipeline Now which will result in a failed build and console output showing:

PS: Installing a new plugin will probably require some time(1-2 weeks)/scanning/approval process from Security team, so not an option I think, at least until that approval happens. Ex: https://plugins.jenkins.io/build-user-vars-plugin/

解决方案

To avoid build failure, for now, I enabled try and catch and setting value for BUILD_USER if getCause(...) is going to fail ... as when someone clicks on the side-bar link Scan MultiBranch Pipeline Now, then console output or Jenkins doesn't set a USER who clicked on that side-bar link to launch the build (if there are any changes to be built) and shows Branch Indexing as first line in output (instead of showing: Started by user <some name> (someUserID)).

Thus, the following will set BUILD_USER to a meaningful value and won't FAIL the build.

@NonCPS
def getBuildUser() {
        def build = currentBuild.rawBuild
        def BUILD_USER = "ToBeSet"

        try {
             def cause = build.getCause(hudson.model.Cause.UserIdCause.class)
             BUILD_USER = cause.getUserName()
        } catch(Exception ex) {
             println "\n\n-- Build caused by either Multi-Branch Pipeline Scanning -or- Timer i.e. not directly by a logged in user\n";
             BUILD_USER = "Multi_Branch_Scan_or_Timer"
        }

        return BUILD_USER
}

I'll still like to know if there's a way, we can find, who clicked on the side-bar link (logged in user), will poke into it.

这篇关于Jenkinsfile-Jenkins构建用户getUserName()NullPointerException:无法在空对象上调用方法getUserName()Mutli Branch Indexing Scanning的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆