Re: [Pipeline] @NonCPS causes "sh" to hang with parallel steps

[Ann B]

Very helpful Jorgen!  I have also spent hours on this issue.  

Ann

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/b43cd792-693e-44b9-8ee9-9dab5da18bf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Creating Jenkins slaves using kubernetes-plugin that restart on node failures

[Art Baldini]

Hi Sam,
We are still trying to come up with the best work-around. Currently we are
kicking off a the build/job and returning immediately. Then we have another
job that monitors the status of the first job.  Definitely not an ideal
situation, but it works for now.

On Wed, Oct 18, 2017 at 12:32 AM, Sam Beckwith III <
sbeckwith...@responsiveed.com> wrote:

> Howdy, Cooper99!
>
> I am encountering this as well, sir.  If I may ask, how did you resolved
> this?
>
> You understand this but others may not: This is a tricky situation.
> Without the functionality to fail the job on disconnection from the node in
> this context, we end up in an endlessly suspended/waiting state. Wrapping
> this in a timeout is quite undesirable because our task in may take a
> variable amount of time to complete meaning our job, which will fail due to
> the disconnect, will sit unnecessarily until the timeout.
>
> It is far more desirable to fail fast.
>
> -Sam
>
> On Tuesday, August 29, 2017 at 2:34:21 PM UTC-5, Cooper99 wrote:
>>
>> Hi Carlos,
>>
>> Thanks for the prompt reply.
>> What I have seen is that when the node is deleted the slave/pod doesn't
>> crash, it is just deleted.  Then the Jenkins master just sits there waiting
>> for the slave to return with the following output:
>>
>> Cannot contact default-6b0e4a2d33a: java.io.IOException: remote file 
>> operation failed: /home/jenkins/workspace/installer/Run_Installer at 
>> hudson.remoting.Channel@1925c5c0:JNLP4-connect connection from 
>> 192.168.3.18/192.168.3.18:46497: hudson.remoting.ChannelClosedException: 
>> channel is already closed
>>
>>
>> Art.
>>
>>
>> On Tuesday, August 29, 2017 at 11:50:08 AM UTC-4, Carlos Sanchez wrote:
>>>
>>> It doesn't restart the agents because as soon as the agent crashes the
>>> build will fail. So there is no point in restarting them
>>>
>>> On Tue, Aug 29, 2017 at 5:30 PM, Cooper99  wrote:
>>>
 I am new to Jenkins so this may be a simple question.  I am using the
 kubernetes-plugin to dynamically create Jenkins slaves. The one thing I
 have noticed is that when using the plugin to create the slaves is if a
 node gets deleted the slave pod is running on, the slave pod is not
 restarted.  I am not sure if this is a configuration error on my part or
 just the way it is.  It seems that based on this article:
 https://www.infoq.com/articles/scaling-docker-kubernetes-v1 that
 having the slaves restart when a node goes down would always be desired.
 I am using Jenkins 2.66 and kubernetes-plugin 0.11 on Kubernetes 1.6.2.

 Thanks.

 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-use...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/ms
 gid/jenkinsci-users/4a04bd53-d927-406a-b8ba-6e346a5ece9b%
 40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-users/BwHCEelcOAY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/d1841dec-c4db-4642-b82d-fe90c2a77b3f%40googlegroups.
> com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAJWqcpkO3mXyQEGp%3Dju60RC%3D_m0gfWdbk1x_dfvY%2BcbtBqZU%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to share local Maven repo between nodes?

[Robert Hales]

You can caputre the node name in the first time you use the node and then 
specify it as the node label in the following node steps. 

On Monday, October 23, 2017 at 2:44:37 PM UTC-6, Torsten Reinhard wrote:
>
> Hi, 
>
> I have a large build & deploy pipeline with some stages, running on 
> different nodes. I´m using stash/unstash for transfering the files 
> (sources) between the nodes 
> - but how do I share the artifacts of the local M2 repository so 
> dependencies can be resolved properly?
>
> node(..) {
>   ..
>   stage("Build") {
> // build it
> sh("mvn clean install")
>   }
>   ..
>   stash ( name: 'workspace', useDefaultExcludes: false, excludes: 
> "**/target/**/*.class, **/target/surefire-reports/**")
> }
>
> node(..) {
>   ..
>   stage("Deploy") {
>  sh("deploy.sh.")
>   }
>   ..
> }
>
> node(..) {
>   unstash( name: 'workspace')
>   stage("Test") {
> ..
> sh("mvn test -Pit..")
> ..
>   }
> }
>
> Is there a way (without declarative pipeline) to "reuse" the same node 
> like before? Or do I have to stash/unstash the local repo or parts of it, 
> too?
>
> Any other ideas ?
>
> Thanx for your responses, 
>
> Torsten
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/81d3b97e-2235-46d0-b4b0-80976e29f484%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to share local Maven repo between nodes?

[Torsten Reinhard]

Hi, 

I have a large build & deploy pipeline with some stages, running on 
different nodes. I´m using stash/unstash for transfering the files 
(sources) between the nodes 
- but how do I share the artifacts of the local M2 repository so 
dependencies can be resolved properly?

node(..) {
  ..
  stage("Build") {
// build it
sh("mvn clean install")
  }
  ..
  stash ( name: 'workspace', useDefaultExcludes: false, excludes: 
"**/target/**/*.class, **/target/surefire-reports/**")
}

node(..) {
  ..
  stage("Deploy") {
 sh("deploy.sh.")
  }
  ..
}

node(..) {
  unstash( name: 'workspace')
  stage("Test") {
..
sh("mvn test -Pit..")
..
  }
}

Is there a way (without declarative pipeline) to "reuse" the same node like 
before? Or do I have to stash/unstash the local repo or parts of it, too?

Any other ideas ?

Thanx for your responses, 

Torsten

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/11949777-39a7-4705-9662-389f23af7f5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[Robert Hales]

Enclosing a 'build' step in a node can be roughly equivalent to enclosing 
an ssh command in the node. That ssh command is kicking off some external 
process. The build step is kicking off an external process. This seems like 
completely normal behavior to me. The jobs are not related to each other in 
any way, and they have their own configuration about which nodes they want 
to run on. It doesn't make sense to expect to independent jobs to have some 
kind of coupling like that. 

Can you give some examples of how the node block does not define the node 
properly for any internally executed steps? I have never seen any steps run 
on the wrong node.

On Monday, October 23, 2017 at 10:33:35 AM UTC-6, Steve Turner wrote:
>
> I wouldn't call that behavior "normal".  I'm new to Jenkins pipelines and 
> Groovy scripting, and this has been the single most maddening thing to 
> overcome in my attempts to learn the environment.  On what planet does it 
> make sense that enclosing something in a node block, where the only 
> argument is a node label, and where the block is enclosed in {} braces 
> (which defines an isolated "scope" in every other language I can think of) 
> does not cause the label to become used as the default for everything 
> defined therein?  The backflips you have to go through to overcome this are 
> ridiculous.  I find both the "node" and "agent" constructs as implemented 
> by the Jenkins pipeline mechanism to be completely useless.
>
> On Wednesday, December 14, 2016 at 6:42:09 AM UTC-6, mpapo - Michael 
> Pailloncy wrote:
>>
>> IIUC, it's a normal behaviour.
>>
>> The "build" pipeline step triggers the job job1 without any node 
>> "context" (a bit like if you trigger it manually), so the default label of 
>> job1 is used in this case. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/b3e2f1e7-1e28-4d63-a7c9-b225b8d154a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[Robert Hales]

In reference to this:  >>it seems strange to me that the pipeline "build" 
step triggers jobs without node context. This implies web-interface driven 
configuration of a job to be made and the cumbersome parameterized "build" 
step syntax to be used to run the job at the proper node.
As far as I know, Pipeline plugin is meant to get rid of such 
inconveniences.

I think maybe you are missing the point of a pipeline. The OLD way was to 
link a bunch of jobs together in a sudo pipeline. The pipeline scripts are 
meant to bring all those individual jobs together into a single pipeline 
script, now divided into stages (instead of independent jobs). If you want 
to join a bunch of jobs in and upstream and downstream configuration, you 
can do that with freestyle jobs and a couple plugins. If you want to build 
a pipeline, put it all in one job with advanced logic and greater control 
of how to combine those pieces together (including things like controlling 
the node).  

One big question is why do you want to keep it on the same node? If you are 
trying to access files in build B that were created in build A using a 
pipeline, then keeping them on the same node is prone to failures. There is 
no guarantee where those files will end up or that they will always exist.  
Usually Stash and Unstash is the right way to handle this rather than 
forcing a node. 

On Wednesday, December 14, 2016 at 6:18:24 AM UTC-7, alexand...@gmail.com 
wrote:
>
> Thank you for fast reply, Michael.
> I got the point.
>
> I've already tried NodeLabel Parameter plugin with parameterized pipeline 
> build job step. But it haven't worked for me.
> Soon I'll publish appropriate topic about this way you proposed that 
> doesn't work for me for unknown reason.
> The pipeline script I've tried is:
>
> build job: 'job2',
> parameters: [
> [
>  $class: 'LabelParameterValue',
>name: 'NODE_NAME',
>   value: 'label1'
> ]
> ]
>
> At this case 'job2' is configured with NodeLabel Parameter plugin to 
> accept 'NODE_NAME' named parameter as Label Parameter.
> The job 'job2' is triggered successfully at the certain node if I use a 
> job with appropriate Parameterized Trigger post-build action with 
> NodeLabel-parameter NODE_NAME and label 'label1' as upstream one.
>
>
> And at the 1st case without NodeLabel Parameter plugin but with pipeline 
> 'node'-construct
> it seems strange to me that the pipeline "build" step triggers jobs 
> without node context. This implies web-interface driven configuration of a 
> job to be made and the cumbersome parameterized "build" step syntax to be 
> used to run the job at the proper node.
> As far as I know, Pipeline plugin is meant to get rid of such 
> inconveniences.
> So as for me it would be pretty natural and convenient if 
> pipeline-build-step triggered jobs with pipeline node context (nodes 
> assigned through pipeline 'node'-construct like:
> 'node () {  }'
> ).
>
> Kind regards,
> Alexander.
>
>
> On Wednesday, December 14, 2016 at 3:42:09 PM UTC+3, mpapo - Michael 
> Pailloncy wrote:
>>
>> IIUC, it's a normal behaviour.
>>
>> The "build" pipeline step triggers the job job1 without any node 
>> "context" (a bit like if you trigger it manually), so the default label of 
>> job1 is used in this case. 
>>
>> If you want to trigger job1 with a specific label, you should have a look 
>> to this plugin : 
>> https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin  
>> However, I never used it inside a Jenkins Pipeline.
>>
>> Michaël
>>
>> 2016-12-14 13:23 GMT+01:00 :
>>
>>> Hi,
>>>
>>> I'm trying to run a job at the node assigned (not the master node), but 
>>> the job runs at any free node available (often it is the master node 
>>> actually).
>>>
>>> Here's my pipeline script:
>>>
>>> node('label1') {
>>>   echo "Actual node name: $env.NODE_NAME ."
>>>   build job: 'job1'
>>> }
>>> node('master') {
>>>   echo "Actual node name: $env.NODE_NAME ."
>>> }
>>>
>>> My master node is not labeled with label 'label1'.
>>> Only one of my slave nodes is labeled with label 'label1'.
>>>
>>> I see at a build's Console Output that the 1st echo is executed at the 
>>> slave node with label 'label1'. And the 2nd echo is executed at the master 
>>> node.
>>> But 'job1' is executed at the master node also.
>>> I think that for my pipeline script 'job1' should be executed at the 
>>> slave node labeled with 'label1'.
>>> 'job1' is allowed to run at any node (this is configured at the job's 
>>> configuration).
>>>
>>> Is this behavior is correct? Or is it a bug when build-job-step ignores 
>>> pipeline node assignment?
>>>
>>> For now I use Jenkins 2.8 and Pipeline Plugin 2.4 .
>>> I've tried both Windows and Linux slaves node with this case (got the 
>>> same result). My master node is on Linux.
>>>
>>> Best regards,
>>> Alexander.
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins 

Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[Steve Turner]

I wouldn't call that behavior "normal".  I'm new to Jenkins pipelines and 
Groovy scripting, and this has been the single most maddening thing to 
overcome in my attempts to learn the environment.  On what planet does it 
make sense that enclosing something in a node block, where the only 
argument is a node label, and where the block is enclosed in {} braces 
(which defines an isolated "scope" in every other language I can think of) 
does not cause the label to become used as the default for everything 
defined therein?  The backflips you have to go through to overcome this are 
ridiculous.  I find both the "node" and "agent" constructs as implemented 
by the Jenkins pipeline mechanism to be completely useless.

On Wednesday, December 14, 2016 at 6:42:09 AM UTC-6, mpapo - Michael 
Pailloncy wrote:
>
> IIUC, it's a normal behaviour.
>
> The "build" pipeline step triggers the job job1 without any node "context" 
> (a bit like if you trigger it manually), so the default label of job1 is 
> used in this case. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/2424b270-68d1-48b7-aac1-4a8298a36c89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unable start Jenkins after upgrading java version to 1.8.Jenkins 1.159.And facing below exception

[BEDJAOUI DJOUNAYDI]

Hello,

Stop the Jenkins server.
rename directory: C:\Users\support \.jenkins by C:\Users\support\.Old_jenkins
Replace the old jenkins.war with the new one
restart Jenkins .


Good luck.


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/ad147158-89d1-4fc4-927a-dac4124121f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: No page found 'index.jelly' for class hudson.scm.listtagsparameter.ListSubversionTagsParameterValue

[Slide]

I believe you want ListSubversionTagsParameterDefinition instead of
ListSubversionTagsParameterValue.

On Mon, Oct 23, 2017, 05:32 Marjo Hartman  wrote:

> Jenkins 2.85
> Pipeline 2.5
> Subversion plugin 2.9
>
> I have defined a pipeline script, where I request some additional
> parameters along the way:
>
> def InputTST = input(
> id: 'InputTST',
> message: 'Promote to TST',
> parameters: [
> [$class: 'StringParameterDefinition', description: 'Config
> ArtifactId for TST', name: 'ConfigArtifactIdTST'],
> [$class: 'StringParameterDefinition', description: 'Code
> ArtifactId for TST', name: 'CodeArtifactIdTST'],
> [$class: 'StringParameterDefinition', description:
> 'Username for TST', name: 'UsernameTST'],
> [$class: 'hudson.model.PasswordParameterDefinition',
> description: 'Password for TST', name: 'PasswordTST'],
> [$class: 'TextParameterDefinition', description:
> 'Overruled TST', name: 'OverruledTST'],
> [$class:
> 'hudson.scm.listtagsparameter.ListSubversionTagsParameterValue',
> description: 'FileName for TST', name: 'FileNameTST', tagsDir: ' path>', credentialsId: ''],
> [$class: 'BooleanParameterDefinition', description:
> 'Confirm TST', name: 'ConfirmTST']
> ])
>
> When running the pipeline it gets to the stage where it asks for the
> additional parameters, and then it fails with the stack trace shown below.
>
> What am I doing wrong?
>
> org.apache.commons.jelly.JellyTagException: 
> jar:file:/u01/Jenkins/home/plugins/pipeline-input-step/WEB-INF/lib/pipeline-input-step.jar!/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution/index.jelly:11:55:
>   No page found 'index.jelly' for class 
> hudson.scm.listtagsparameter.ListSubversionTagsParameterValue
>   at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:124)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
>   at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
>   at 
> org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>   at 
> org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
>   at 
> org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
>   at 
> org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
>   at 
> org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>   at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
>   at 
> org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
>   at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>   at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
>   at 
> org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:95)
>   at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
>   at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
>   at 
> org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
>   at 
> org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
>   at 
> org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>   at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>   at 
> org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
>   at 
> org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>   at 
> org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
>   at 
> org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
>   at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
>   at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>   at 
> 

No page found 'index.jelly' for class hudson.scm.listtagsparameter.ListSubversionTagsParameterValue

[Marjo Hartman]

Jenkins 2.85
Pipeline 2.5
Subversion plugin 2.9

I have defined a pipeline script, where I request some additional 
parameters along the way:

def InputTST = input(
id: 'InputTST',
message: 'Promote to TST',
parameters: [
[$class: 'StringParameterDefinition', description: 'Config 
ArtifactId for TST', name: 'ConfigArtifactIdTST'],
[$class: 'StringParameterDefinition', description: 'Code 
ArtifactId for TST', name: 'CodeArtifactIdTST'],
[$class: 'StringParameterDefinition', description: 
'Username for TST', name: 'UsernameTST'],
[$class: 'hudson.model.PasswordParameterDefinition', 
description: 'Password for TST', name: 'PasswordTST'],
[$class: 'TextParameterDefinition', description: 'Overruled 
TST', name: 'OverruledTST'],
[$class: 
'hudson.scm.listtagsparameter.ListSubversionTagsParameterValue', 
description: 'FileName for TST', name: 'FileNameTST', tagsDir: '', credentialsId: ''],
[$class: 'BooleanParameterDefinition', description: 
'Confirm TST', name: 'ConfirmTST']
])

When running the pipeline it gets to the stage where it asks for the 
additional parameters, and then it fails with the stack trace shown below.

What am I doing wrong?

org.apache.commons.jelly.JellyTagException: 
jar:file:/u01/Jenkins/home/plugins/pipeline-input-step/WEB-INF/lib/pipeline-input-step.jar!/org/jenkinsci/plugins/workflow/support/steps/input/InputStepExecution/index.jelly:11:55:
  No page found 'index.jelly' for class 
hudson.scm.listtagsparameter.ListSubversionTagsParameterValue
at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:124)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at 
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:95)
at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
at 
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
at 
org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
at 
org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
at 
org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
at 

BlueOcean observations from user

[Sverre Moe]

Here follows some observations from running Jenkins in Blue Ocean:

I know BluOcean is not yet finished:
https://jenkins.io/projects/blueocean/roadmap/
A small list. I had expected more, but perhaps it near finish.

Hope that some of my observation might lead to improvements on BlueOcean 
because I like it a lot. It is a huge step up in user interface design.
What I like most from BlueOcean is that I can see the build log output from 
each build node alone, while in classic view it was all mixed together.

1) Slow initial loading:
Clicking on a Pipeline: activities takes several seconds to finish loading.
Clicking on Branches, takes several seconds to finish loading.

2) After initial loading on Multibranch Pipeline in BlueOcean it loads 
faster the second time, but still a little lag.
"Show more" takes a few seconds to load.
Loading back to Pipelines takes a few seconds before it is finished loading.

3) Is it not possible to select view to show in BlueOcean?
We have a lot of projects, and it would be helpful to limit which views 
project is listed.
Some projects are also Coverity, maintenance and tools Pipelines and are 
not important for the main user to see.

4) Warnings in the log output.
Lots of the following WARNING
Specially when I click on Show more

Oct 18, 2017 4:20:16 PM hudson.XmlFile replaceIfNotAtTopLevel
WARNING: JENKINS-45892: reference to pipe1 #319 being saved from unexpected 
/var/lib/jenkins/jobs/pipe1/builds/319/workflow/6-parallel-synthetic.xml
java.lang.IllegalStateException
at hudson.XmlFile.replaceIfNotAtTopLevel(XmlFile.java:210)
at hudson.model.Run.writeReplace(Run.java:1929)
at sun.reflect.GeneratedMethodAccessor173.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callWriteReplace(SerializationMethodInvoker.java:89)
at 
hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:141)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at 
com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
at 
hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
at 
hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
at 
hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:224)
at 
com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:138)
at 
hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:209)
at 
hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:150)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at 
com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at 
com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/a0a3373d-0647-40c4-b1d9-e8bd0123379e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.