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

Downstream jobs not associated with upstream parent job properly

      Using the parameterized build trigger and email-ext

      1) Create downstream job that emails the requestor using email-ext
      2) Create upstream [Edit: multi-configuration only!] job that triggers downstream job using a condition to run the parameterized build trigger plugin
      3) Run upstream job: receive null ptr exception when email-ext tries to email requestor.

          [JENKINS-12410] Downstream jobs not associated with upstream parent job properly

          Sami Salonen added a comment -

          I have two free-style projects. The upstream project has a manual promotion process that triggers the downstream project. Jenkins default promotion action Build other projects works as expected whereas promotion actions Trigger/call builds on other projects and Trigger parameterized build on other projects by Parameterized Trigger plugin result in the following exception in the downstream project when trying to send an email to requesters. There is no additional info in jenkins log file, it just repeats the stack dump.

          Jenkins 1.480.3, Email-ext 2.28, Parameterized Trigger 2.17

          Email was triggered for: Success
          Sending email for trigger: Success
          NOT overriding default server settings, using Mailer to create session
          messageContentType = text/html; charset=UTF-8
          Adding recipients from recipient list
          Sending to requester
          ERROR: Could not send email as a part of the post-build publishers.
          java.lang.NullPointerException
          	at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:537)
          	at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:304)
          	at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:296)
          	at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:256)
          	at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:718)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:693)
          	at hudson.model.Build$BuildExecution.cleanUp(Build.java:192)
          	at hudson.model.Run.execute(Run.java:1546)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          	at hudson.model.ResourceController.execute(ResourceController.java:88)
          	at hudson.model.Executor.run(Executor.java:237)
          Some error occured trying to send the email...check the Jenkins log
          Finished: SUCCESS
          

          Sami Salonen added a comment - I have two free-style projects. The upstream project has a manual promotion process that triggers the downstream project. Jenkins default promotion action Build other projects works as expected whereas promotion actions Trigger/call builds on other projects and Trigger parameterized build on other projects by Parameterized Trigger plugin result in the following exception in the downstream project when trying to send an email to requesters. There is no additional info in jenkins log file, it just repeats the stack dump. Jenkins 1.480.3, Email-ext 2.28, Parameterized Trigger 2.17 Email was triggered for : Success Sending email for trigger: Success NOT overriding default server settings, using Mailer to create session messageContentType = text/html; charset=UTF-8 Adding recipients from recipient list Sending to requester ERROR: Could not send email as a part of the post-build publishers. java.lang.NullPointerException at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:537) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:304) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:296) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:256) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:718) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:693) at hudson.model.Build$BuildExecution.cleanUp(Build.java:192) at hudson.model.Run.execute(Run.java:1546) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237) Some error occured trying to send the email...check the Jenkins log Finished: SUCCESS

          ikedam added a comment -
          • Does it always happen?
          • Would you attach build.xml of the build raised the error?

          ikedam added a comment - Does it always happen? Would you attach build.xml of the build raised the error?

          Sami Salonen added a comment -

          The problem used to be permanent in my case. The good news is that I cannot reproduce it anymore. I tried to reproduce it in two different environments without luck:
          Env 1: Jenkins 1.509.4 + Email Extension 2.36 + Parameterized Trigger 2.22
          Env 2: Jenkins 1.532.2 + Email Extension 2.37.2 + Parameterized Trigger 2.22

          I cannot comment on the original problem regarding multi-configuration projects though.

          Sami Salonen added a comment - The problem used to be permanent in my case. The good news is that I cannot reproduce it anymore. I tried to reproduce it in two different environments without luck: Env 1: Jenkins 1.509.4 + Email Extension 2.36 + Parameterized Trigger 2.22 Env 2: Jenkins 1.532.2 + Email Extension 2.37.2 + Parameterized Trigger 2.22 I cannot comment on the original problem regarding multi-configuration projects though.

          ikedam added a comment -

          I could not reproduce the problem, too.
          Jenkins 1.532.1 + Email-ext 2.37.2 + Parameterized-trigger 2.22.

          What I tried:

          • Run parameterized trigger without parameters as a publisher from multi-configuration project, and always send email to requester in the downstream.
          • Run non-blocking parameterized trigger without parameters as a builder from multi-configuration project, and always send email to requester in the downstream.
          • Run blocking parameterized trigger without parameters as a builder from multi-configuration project, and always send email to requester in the downstream.

          I think it is already resolved in some version:

          • There is another ticket JENKINS-12300, which seems same to this and it is reported as resolved (I'm not sure how it is resolved).
          • Current codes of email-ext seems completely different from that of Email-ext 2.28.

          I'll close this ticket as Resolved if there is no new reports in one month.

          ikedam added a comment - I could not reproduce the problem, too. Jenkins 1.532.1 + Email-ext 2.37.2 + Parameterized-trigger 2.22. What I tried: Run parameterized trigger without parameters as a publisher from multi-configuration project, and always send email to requester in the downstream. Run non-blocking parameterized trigger without parameters as a builder from multi-configuration project, and always send email to requester in the downstream. Run blocking parameterized trigger without parameters as a builder from multi-configuration project, and always send email to requester in the downstream. I think it is already resolved in some version: There is another ticket JENKINS-12300 , which seems same to this and it is reported as resolved (I'm not sure how it is resolved). Current codes of email-ext seems completely different from that of Email-ext 2.28. I'll close this ticket as Resolved if there is no new reports in one month.

          ikedam added a comment -

          Cannot reproduce in the latest version.
          Looks fixed in some version.

          ikedam added a comment - Cannot reproduce in the latest version. Looks fixed in some version.

          Ken Beal added a comment -

          We are experiencing this. We have a job flow like Detect -> Monitor -> Deploy -> Test1 -> Test2 -> Test3 -> Upload -> Report -> Delete.

          Not all the VMs we deploy are being deleted. Upon investigation, when I looked at the Delete job at the top of its console output, it shows the chain of jobs that ran.

          However, when I then looked at "Deploy+1", it ran "Test1+1", but looking in that job's console output, it shows it ran Test2 – not "Test2+1"!

          We are using the Parameterized Trigger Plugin (latest version, 2.25), as well as Email-Ext (latest version, 2.38.1).

          Ken Beal added a comment - We are experiencing this. We have a job flow like Detect -> Monitor -> Deploy -> Test1 -> Test2 -> Test3 -> Upload -> Report -> Delete. Not all the VMs we deploy are being deleted. Upon investigation, when I looked at the Delete job at the top of its console output, it shows the chain of jobs that ran. However, when I then looked at "Deploy+1", it ran "Test1+1", but looking in that job's console output, it shows it ran Test2 – not "Test2+1"! We are using the Parameterized Trigger Plugin (latest version, 2.25), as well as Email-Ext (latest version, 2.38.1).

          ikedam added a comment -

          @kbeal I cannot get what you say at all.
          What is VM? I cannot get how a virtual machine relates to this problem.
          What is +1?
          Which job reported NPE?

          ikedam added a comment - @kbeal I cannot get what you say at all. What is VM? I cannot get how a virtual machine relates to this problem. What is +1? Which job reported NPE?

          Ken Beal added a comment -

          The "Deploy" part creates a VM; the "Delete" part deletes it.

          It looks like Jenkins is "getting confused" because we're seeing one job flow "merge" with another. Specific numbers:

          Detect #33086 -> Monitor #637 -> Deploy #531 -> Test1 #413 -> Test2 #360 -> Test3 #308 -> Upload #301 -> Report #305 -> Delete #318

          Detect #33142 -> Monitor #641 -> Deploy #532 -> Test1 #414 -> Test2 #360

          Looking at Test2 #361, it appears to have crashed, which may be why Jenkins then "decided" that Test1 #414 -> Test2 #360.

          So "Test2+1" would have been #361, which was expected, not #360 which we saw in the console output of Test1 #414 (as well as #413).

          At the very least it should say build #361 ran, but likely there's stuff happening after the build is started that records back to the upstream job? (An odd design, it should know it's #361 at the time it started – which is, understandably, a little bit after Test1 finished, but that information should have been set a moment after #361 started, and not be "corrupted" by #361 crashing hours later – note that this job takes 4-8 hours to run, and generates a large log, around 575 MB, in case that's relevant.)

          The crash from Test2 #361 is below, to the end of this comment. It was run on a slave ("slave3"), which #360 was also built on (e.g., it's not always crashing when it is run on this slave).

          The beginning of the below is the end of a SOAP call, which is part of the tests that are run, and then it crashed. #361's log was only 80 MB, as it crashed 1 hour 22 min in. #360's log was 575 MB, and ran for 4 hours 40 minutes.

          ===================================================
          [...]
          [testng] </SOAP-ENV:Body>
          [testng] </SOAP-ENV:Envelope>
          [testng]
          FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
          hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
          at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41)
          at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34)
          at hudson.remoting.Request.call(Request.java:174)
          at hudson.remoting.Channel.call(Channel.java:739)
          at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168)
          at $Proxy70.join(Unknown Source)
          at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:951)
          at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137)
          at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97)
          at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
          at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
          at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:745)
          at hudson.model.Build$BuildExecution.build(Build.java:198)
          at hudson.model.Build$BuildExecution.doRun(Build.java:159)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:518)
          at hudson.model.Run.execute(Run.java:1704)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:88)
          at hudson.model.Executor.run(Executor.java:231)
          Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
          at hudson.remoting.Request.abort(Request.java:299)
          at hudson.remoting.Channel.terminate(Channel.java:802)
          at hudson.remoting.Channel$2.terminate(Channel.java:483)
          at hudson.remoting.AbstractByteArrayCommandTransport$1.terminate(AbstractByteArrayCommandTransport.java:72)
          at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:184)
          at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:563)
          at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
          at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
          at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
          at java.util.concurrent.FutureTask.run(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)
          Caused by: java.io.IOException: Failed to abort
          ... 9 more
          Caused by: java.io.IOException: An existing connection was forcibly closed by the remote host
          at sun.nio.ch.SocketDispatcher.read0(Native Method)
          at sun.nio.ch.SocketDispatcher.read(Unknown Source)
          at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
          at sun.nio.ch.IOUtil.read(Unknown Source)
          at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
          at org.jenkinsci.remoting.nio.FifoBuffer$Pointer.receive(FifoBuffer.java:136)
          at org.jenkinsci.remoting.nio.FifoBuffer.receive(FifoBuffer.java:306)
          at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:496)
          ... 7 more

          Ken Beal added a comment - The "Deploy" part creates a VM; the "Delete" part deletes it. It looks like Jenkins is "getting confused" because we're seeing one job flow "merge" with another. Specific numbers: Detect #33086 -> Monitor #637 -> Deploy #531 -> Test1 #413 -> Test2 #360 -> Test3 #308 -> Upload #301 -> Report #305 -> Delete #318 Detect #33142 -> Monitor #641 -> Deploy #532 -> Test1 #414 -> Test2 #360 Looking at Test2 #361, it appears to have crashed, which may be why Jenkins then "decided" that Test1 #414 -> Test2 #360. So "Test2+1" would have been #361, which was expected, not #360 which we saw in the console output of Test1 #414 (as well as #413). At the very least it should say build #361 ran, but likely there's stuff happening after the build is started that records back to the upstream job? (An odd design, it should know it's #361 at the time it started – which is, understandably, a little bit after Test1 finished, but that information should have been set a moment after #361 started, and not be "corrupted" by #361 crashing hours later – note that this job takes 4-8 hours to run, and generates a large log, around 575 MB, in case that's relevant.) The crash from Test2 #361 is below, to the end of this comment. It was run on a slave ("slave3"), which #360 was also built on (e.g., it's not always crashing when it is run on this slave). The beginning of the below is the end of a SOAP call, which is part of the tests that are run, and then it crashed. #361's log was only 80 MB, as it crashed 1 hour 22 min in. #360's log was 575 MB, and ran for 4 hours 40 minutes. =================================================== [...] [testng] </SOAP-ENV:Body> [testng] </SOAP-ENV:Envelope> [testng] FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:739) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168) at $Proxy70.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:951) at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:745) at hudson.model.Build$BuildExecution.build(Build.java:198) at hudson.model.Build$BuildExecution.doRun(Build.java:159) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:518) at hudson.model.Run.execute(Run.java:1704) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:802) at hudson.remoting.Channel$2.terminate(Channel.java:483) at hudson.remoting.AbstractByteArrayCommandTransport$1.terminate(AbstractByteArrayCommandTransport.java:72) at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:184) at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:563) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.io.IOException: Failed to abort ... 9 more Caused by: java.io.IOException: An existing connection was forcibly closed by the remote host at sun.nio.ch.SocketDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(Unknown Source) at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source) at sun.nio.ch.IOUtil.read(Unknown Source) at sun.nio.ch.SocketChannelImpl.read(Unknown Source) at org.jenkinsci.remoting.nio.FifoBuffer$Pointer.receive(FifoBuffer.java:136) at org.jenkinsci.remoting.nio.FifoBuffer.receive(FifoBuffer.java:306) at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:496) ... 7 more

          ikedam added a comment -

          @kbeal I cannot get why you thouht your problem relates to this issue at all.
          It sounds that your problem rather relates to JENKINS-7557.

          ikedam added a comment - @kbeal I cannot get why you thouht your problem relates to this issue at all. It sounds that your problem rather relates to JENKINS-7557 .

          ikedam added a comment -

          Invalid reopen

          ikedam added a comment - Invalid reopen

            huybrechts huybrechts
            joelcollinsdc Joel Collins
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: