Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-64978

First use of the plugin fails on jenkins reboot

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • Jenkins 2.231
      p4-plugin 1.11.3

      We were testing upgrading to the latest version of p4-plugin 1.11.3 on Jenkins 2.231 and encountered the following issue on the first build triggered after reboot. This was observed reliably several times and does not occur on our older version of the plugin. Issue only occurred on the first build.

      ============

      [Pipeline] { (SCM (win64))[Pipeline]

      { (SCM (win64)) [Pipeline] checkoutExecutor number at runtime: 0[Pipeline] }

      [Pipeline] // stage[Pipeline] stage[Pipeline]

      { (Archive (win64))[Pipeline] bat============ Skip Pipeline]}

      Failed in branch win64[Pipeline] // parallel[Pipeline] End of Pipeline

      hudson.remoting.ProxyException: java.awt.AWTError: Assistive Technology not found: org.GNOME.Accessibility.AtkWrapper at java.awt.Toolkit.loadAssistiveTechnologies(Toolkit.java:807) at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:886) at java.awt.Desktop.isDesktopSupported(Desktop.java:169) at com.perforce.p4java.server.callback.DefaultBrowserCallback.<init>(DefaultBrowserCallback.java:15) at com.perforce.p4java.impl.mapbased.server.Server.<init>(Server.java:203) at com.perforce.p4java.impl.mapbased.rpc.RpcServer.<init>(RpcServer.java:87) at com.perforce.p4java.impl.mapbased.rpc.OneShotServerImpl.<init>(OneShotServerImpl.java:64) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at com.perforce.p4java.server.ServerFactory.getOptionsServer(ServerFactory.java:322) at org.jenkinsci.plugins.p4.client.ConnectionFactory.getRawConnection(ConnectionFactory.java:131) at org.jenkinsci.plugins.p4.client.ConnectionFactory.getConnection(ConnectionFactory.java:48) at org.jenkinsci.plugins.p4.client.ConnectionHelper.connect(ConnectionHelper.java:146) at org.jenkinsci.plugins.p4.client.ConnectionHelper.connectionRetry(ConnectionHelper.java:189) at org.jenkinsci.plugins.p4.client.ConnectionHelper.<init>(ConnectionHelper.java:112) at org.jenkinsci.plugins.p4.client.ClientHelper.<init>(ClientHelper.java:99) at org.jenkinsci.plugins.p4.tasks.CheckoutTask.initialise(CheckoutTask.java:64) at org.jenkinsci.plugins.p4.PerforceScm.checkout(PerforceScm.java:550) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:124) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80) at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47) 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:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)Finished: FAILURE
      

          [JENKINS-64978] First use of the plugin fails on jenkins reboot

          Karl Wirth added a comment -

          Hi kangthejenkin

          Thanks for highlighting this.I have done the same upgrade and dont see the error. It's also weird that this seems to be a dependency error:

          java.awt.AWTError: Assistive Technology not found
          

          and it is mentioned in JENKINS-39636 and on Java related forums.

          • What version were you upgrading from?
          • Did you upgrade Jenkins also?
          • What OS (including version) are the salves running?
          • What happens if you edit and save the job first? Does the first build still fail?
          • What happens if the first build runs on the master server? Does it still fail?
          • Please get me your jenkinsfile - Note if this contains sensitive information please email it to support@perforce.com.

          Karl Wirth added a comment - Hi kangthejenkin Thanks for highlighting this.I have done the same upgrade and dont see the error. It's also weird that this seems to be a dependency error: java.awt.AWTError: Assistive Technology not found and it is mentioned in JENKINS-39636 and on Java related forums. What version were you upgrading from? Did you upgrade Jenkins also? What OS (including version) are the salves running? What happens if you edit and save the job first? Does the first build still fail? What happens if the first build runs on the master server? Does it still fail? Please get me your jenkinsfile - Note if this contains sensitive information please email it to support@perforce.com.

          Rami Alia added a comment - - edited

          Hi Karl, sorry for the late reply on this, I'll have to double check that my notifications are working.

          What version were you upgrading from? - 1.8.9
          Did you upgrade Jenkins also? - No
          What OS (including version) are the salves running? - Master is Debian 9.12, Nodes are Windows 10
          What happens if you edit and save the job first? Does the first build still fail? - I'm unable to trivially verify this. The job retrieves a groovy workflow script from swarm via web request then executes it like so

          def wf = httpRequest acceptType: 'TEXT_PLAIN', contentType: 'TEXT_PLAIN', url: "http://ddddddddddddd/workflow.groovy"
          evaluate wf.content
          

          What happens if the first build runs on the master server? Does it still fail? - Our master is a linux machine that doesn't run builds, all builds run on windows nodes.
          Please get me your jenkinsfile - Note if this contains sensitive information please email it to support@perforce.com. - Attached below the only scm step in the script

          	stage ("SCM ($platform.name)") {
          							checkout changelog: i == 2, poll: false, scm: [
          								$class: 'PerforceScm',
          								browser: [
          									$class: 'SwarmBrowser',
          									url: 'blah.com'
          								],
          								credential: 'bbbb',
          								populate: [
          									$class: 'AutoCleanImpl',
          									delete: true,
          									modtime: true,
          									parallel: [
          										enable: true,
          										minbytes: '1024',
          										minfiles: '1',
          										path: 'p4',
          										threads: '4'
          									],
          									pin: change,
          									quiet: true,
          									replace: true
          								],
          								workspace: [
          									$class: 'ManualWorkspaceImpl',
          									charset: 'none',
          									name: "jenkins-$env.NODE_NAME-blah-Swarm-$streamname",
          									pinHost: false,
          									spec: [
          										allwrite: true,
          										clobber: true,
          										compress: false,
          										line: 'UNIX',
          										locked: false,
          										modtime: true,
          										rmdir: true,
          										streamName: "//blah/$streamname",
          										view: ''
          									]
          								]
          							]
          						}
          

          Rami Alia added a comment - - edited Hi Karl, sorry for the late reply on this, I'll have to double check that my notifications are working. What version were you upgrading from? - 1.8.9 Did you upgrade Jenkins also? - No What OS (including version) are the salves running? - Master is Debian 9.12, Nodes are Windows 10 What happens if you edit and save the job first? Does the first build still fail? - I'm unable to trivially verify this. The job retrieves a groovy workflow script from swarm via web request then executes it like so def wf = httpRequest acceptType: 'TEXT_PLAIN' , contentType: 'TEXT_PLAIN' , url: "http: //ddddddddddddd/workflow.groovy" evaluate wf.content What happens if the first build runs on the master server? Does it still fail? - Our master is a linux machine that doesn't run builds, all builds run on windows nodes. Please get me your jenkinsfile - Note if this contains sensitive information please email it to support@perforce.com. - Attached below the only scm step in the script stage ( "SCM ($platform.name)" ) { checkout changelog: i == 2, poll: false , scm: [ $class: 'PerforceScm' , browser: [ $class: 'SwarmBrowser' , url: 'blah.com' ], credential: 'bbbb' , populate: [ $class: 'AutoCleanImpl' , delete: true , modtime: true , parallel: [ enable: true , minbytes: '1024' , minfiles: '1' , path: 'p4' , threads: '4' ], pin: change, quiet: true , replace: true ], workspace: [ $class: 'ManualWorkspaceImpl' , charset: 'none' , name: "jenkins-$env.NODE_NAME-blah-Swarm-$streamname" , pinHost: false , spec: [ allwrite: true , clobber: true , compress: false , line: 'UNIX' , locked: false , modtime: true , rmdir: true , streamName: " //blah/$streamname" , view: '' ] ] ] }

          Karl Wirth added a comment -

          Hi kangthejenkin  - Thanks. I'll test this here to see if I can reproduce it.

           

          Note: I had never seen that concept of getting a Jenkinsfile from a httpRequest. Is the checkout step in that workflow script and how does $streamname get injected? Is it a global variable in the calling Jenkinsfile?

          Karl Wirth added a comment - Hi kangthejenkin   - Thanks. I'll test this here to see if I can reproduce it.   Note : I had never seen that concept of getting a Jenkinsfile from a httpRequest. Is the checkout step in that workflow script and how does $streamname get injected? Is it a global variable in the calling Jenkinsfile?

          Karl Wirth added a comment -

          I have not been able to reproduce this problem. There is old data stored that is incompatible with the new version of the plugin:

          On my system it was:

          It's possible this bad data caused the crash and a second build cleaned it out.

           

          Marking this as a problem for now.

          Karl Wirth added a comment - I have not been able to reproduce this problem. There is old data stored that is incompatible with the new version of the plugin: On my system it was: It's possible this bad data caused the crash and a second build cleaned it out.   Marking this as a problem for now.

          Rami Alia added a comment -

          Thanks Karl, regarding your note about how we pull the workflow script, it has to do with allowing the workflow to be part of the review process and supporting multiple streams. streamname and review variables are part of the swarm test request.

           

          In the sample below we attempt to pull a workflow script first from the CL, then from the stream, then from the default stream with the Cl and finally the default. It's not very pretty but it allows us to have one jenkins job that can build any related stream and support workflow testing as well.

           

          For example 

          def wf = httpRequest url: "http://swarm.blah.com/view/blah/${streamname}/workflow.groovy?v=%40%3D${review}", validResponseCodes: '100:404'
          if(wf.status >= 400)
          wf = httpRequest url: "http://swarm.blah.com/view/blah/${streamname}/workflow.groovy", validResponseCodes: '100:404'
          if(wf.status >= 400)
          wf = httpRequest url: "http://swarm.blah.com/view/blah/dev/workflow.groovy?v=%40%3D${review}", validResponseCodes: '100:404'
          if(wf.status >= 400)
          wf = httpRequest acceptType: 'TEXT_PLAIN', contentType: 'TEXT_PLAIN', url: "http://swarm.blah.com/view/blah/dev/workflow.groovy"

          evaluate wf.content

           

          There's probably a way to do this better, but it's straightforward and works well.

           

          Cheers

          Rami Alia added a comment - Thanks Karl, regarding your note about how we pull the workflow script, it has to do with allowing the workflow to be part of the review process and supporting multiple streams. streamname and review variables are part of the swarm test request.   In the sample below we attempt to pull a workflow script first from the CL, then from the stream, then from the default stream with the Cl and finally the default. It's not very pretty but it allows us to have one jenkins job that can build any related stream and support workflow testing as well.   For example  def wf = httpRequest url: "http://swarm.blah.com/view/blah/${streamname}/workflow.groovy?v=%40%3D${review}", validResponseCodes: '100:404' if(wf.status >= 400) wf = httpRequest url: "http://swarm.blah.com/view/blah/${streamname}/workflow.groovy", validResponseCodes: '100:404' if(wf.status >= 400) wf = httpRequest url: "http://swarm.blah.com/view/blah/dev/workflow.groovy?v=%40%3D${review}", validResponseCodes: '100:404' if(wf.status >= 400) wf = httpRequest acceptType: 'TEXT_PLAIN', contentType: 'TEXT_PLAIN', url: "http://swarm.blah.com/view/blah/dev/workflow.groovy" evaluate wf.content   There's probably a way to do this better, but it's straightforward and works well.   Cheers

          Karl Wirth added a comment -

          Hi kangthejenkin - Thanks and wow! Every time I think I undserstand how Jenkins works someone shows me a completley new way to use it. Thank you thats a great trick.

          Karl Wirth added a comment - Hi kangthejenkin - Thanks and wow! Every time I think I undserstand how Jenkins works someone shows me a completley new way to use it. Thank you thats a great trick.

            Unassigned Unassigned
            kangthejenkin Rami Alia
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: