-
Bug
-
Resolution: Duplicate
-
Minor
-
None
-
Jenkins 2.32.3 LTS, Pipeline Groovy 2.28, master and slave nodes running Windows Server 2012 R2.
Update (March 7): See comment below; this seems to be triggered by having two webhooks setup in GitHub Enterprise for the same repository.
I'm seeing certain pipeline builds hang after upgrading to the set of SCM API 2 plugins; this didn't happen before that upgrade. So far, I've only seen it for build #1 of a multibranch pipeline job (i.e., a new branch or PR). The manifestation is that the build appears to be running under the build node in question, but never completes. (It just shows the striped progress bar perpetually, until aborted.) The console log, however, shows the build as having failed, with this stack trace:
java.io.IOException: Failed to load build state at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$3.onSuccess(CpsFlowExecution.java:611) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$3.onSuccess(CpsFlowExecution.java:609) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$4$1.run(CpsFlowExecution.java:658) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$1.run(CpsVmExecutorService.java:35) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(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: org.acegisecurity.AccessDeniedException: Please login to access job My Job Name at jenkins.model.Jenkins.getItem(Jenkins.java:2724) at jenkins.model.Jenkins.getItem(Jenkins.java:324) at jenkins.model.Jenkins.getItemByFullName(Jenkins.java:2830) at hudson.model.Run.fromExternalizableId(Run.java:2314) at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.runForDisplay(ExecutorStepExecution.java:384) at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.getDisplayName(ExecutorStepExecution.java:397) at org.jenkinsci.plugins.workflow.support.steps.ExecutorStepExecution$PlaceholderTask.getFullDisplayName(ExecutorStepExecution.java:406) at org.jenkinsci.plugins.workflow.support.pickles.ExecutorPickle$1.printWaitingMessage(ExecutorPickle.java:116) at org.jenkinsci.plugins.workflow.support.pickles.TryRepeatedly$1.run(TryRepeatedly.java:95) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ... 3 more
The text "My Job Name" in the stack trace above replaces the actual job name, although I note that the job name referenced here is actually the parent folder (a standard Cloudbees Folder) containing the multibranch pipeline job, not the multbranch pipeline job itself.
When I abort the stuck job, it asks if I want to abort null (possibly because it has already in fact stopped running?), but then it does abort cleanly. Rerunning the job seems to succeed.
- duplicates
-
-
- Resolved
-