[JIRA] (JENKINS-59704) NoSuchMethodError occurs when promoting a build using parametrized trigger
Title: Message Title Ben Dean commented on JENKINS-59704 Re: NoSuchMethodError occurs when promoting a build using parametrized trigger 3.2 is the version I reverted to when JENKINS-59600 caused problems. 3.4 was supposed to fix those but now this new issue, so I'm back on 3.2 again. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202405.157054141.6875.1572614040717%40Atlassian.JIRA.
[JIRA] (JENKINS-59967) getting 403 for invalid crumb on trigger remote job
Title: Message Title Ben Dean created an issue Jenkins / JENKINS-59967 getting 403 for invalid crumb on trigger remote job Issue Type: Bug Assignee: KaiHsiang Chang Components: parameterized-remote-trigger-plugin Created: 2019-10-28 21:41 Environment: Jenkins 2.198 Parameterized-Remote-Trigger 3.1.0 both jenkins masters running in Kubernetes Priority: Minor Reporter: Ben Dean When I trigger a job from a pipeline with: triggerRemoteJob([ auth : CredentialsAuth(credentials: 'something'), job: jobName, remoteJenkinsName : 'Prod Jenkins', useCrumbCache : true, useJobInfoCache: true, blockBuildUntilComplete: false, parameters : "VERSION=1.2.3", ]) I get a 403 when it is trying to do crsf crumb stuff. On remote jenkins log I see: WARNING hudson.security.csrf.CrumbFilter#doFilter: Found invalid crumb 163***3c. Will check remaining parameters for a valid one... WARNING hudson.security.csrf.CrumbFilter#doFilter: No valid crumb was included in request for /job/prod_folder/job/some_repo/job/default/buildWithParameters by Prod-Build-User. Returning 403.
[JIRA] (JENKINS-43771) EC2 Plugin: Jenkins doesn't wait for cloud-init to finish
Title: Message Title Ben Dean commented on JENKINS-43771 Re: EC2 Plugin: Jenkins doesn't wait for cloud-init to finish Another simpler version of the second part of Mykola Marzhan's workaround is to have this in your init script: sudo cloud-init status --wait Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.181189.1492796392000.9153.1562963940317%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54400) parallel sh step with returnStatus: true causing build failure
Title: Message Title
Ben Dean created an issue
Jenkins / JENKINS-54400
parallel sh step with returnStatus: true causing build failure
Issue Type:
Bug
Assignee:
Unassigned
Components:
durable-task-plugin, workflow-cps-plugin
Created:
2018-11-01 15:38
Environment:
Jenkins 2.147 (from jenkins/jenkins:2.147 docker image) workflow-cps 2.60 durable-task 1.26
Priority:
Minor
Reporter:
Ben Dean
This is maybe related to https://issues.jenkins-ci.org/browse/JENKINS-28822 I have a fairly complicated build that has parallel sections where sh steps run with returnStatus: true. Some of the parallel branches have timeout steps, others do not, but none of the timeouts are around the sh steps, they're usually around an input step. You could say that the pipeline looks something like thi
s:
stage('build') {
parallel([
foo: {
node {
def status = sh(returnStatus: true, script: 'exit 2')
if (status == 2) {
timeout(time: 10, unit: 'DAYS') {
input 'continue?'
}
}
}
},
bar: {
node {
def status = sh(returnStatus: true, script: 'exit 2')
if (status == 2) {
timeout(time: 10, unit: 'DAYS') {
input 'continue?'
}
}
}
}
])
}
And the error I'm getting is only on one of those branches, the
[JIRA] (JENKINS-49836) Cannot view Console logs
Title: Message Title
Ben Dean updated an issue
Jenkins / JENKINS-49836
Cannot view Console logs
Change By:
Ben Dean
On running builds some console logs are working, some are not.When I view finished build, some are working properly, some are empty. !Screen Shot 2018-03-02 at 11.18.25.png |width=977,height=557 !!Screen Shot 2018-03-02 at 11.23.44.png! {noformat}Stack tracejava.lang.IllegalArgumentException: Last unit does not have enough valid bits at java.util.Base64$Decoder.decode0(Base64.java:734) at java.util.Base64$Decoder.decode(Base64.java:526) at hudson.util.UnbufferedBase64InputStream.read(UnbufferedBase64InputStream.java:41) at hudson.util.UnbufferedBase64InputStream.read(UnbufferedBase64InputStream.java:53) at java.io.DataInputStream.readFully(DataInputStream.java:195) at java.io.DataInputStream.readFully(DataInputStream.java:169) at hudson.console.ConsoleNote.readFrom(ConsoleNote.java:241) at hudson.console.ConsoleAnnotationOutputStream.eol(ConsoleAnnotationOutputStream.java:109) at hudson.console.LineTransformationOutputStream.eol(LineTransformationOutputStream.java:60) at hudson.console.LineTransformationOutputStream.write(LineTransformationOutputStream.java:56) at hudson.console.LineTransformationOutputStream.write(LineTransformationOutputStream.java:74) at org.apache.commons.io.output.ProxyOutputStream.write(ProxyOutputStream.java:90) at org.kohsuke.stapler.framework.io.LargeText$HeadMark.moveTo(LargeText.java:314) at org.kohsuke.stapler.framework.io.LargeText.writeLogTo(LargeText.java:229) at hudson.console.AnnotatedLargeText.writeHtmlTo(AnnotatedLargeText.java:168) at hudson.console.AnnotatedLargeText.writeLogTo(AnnotatedLargeText.java:143) at org.kohsuke.stapler.framework.io.LargeText.doProgressText(LargeText.java:264) at hudson.console.AnnotatedLargeText.doProgressiveHtml(AnnotatedLargeText.java:91) at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627) at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:343) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:184) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:117) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:129) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715)Caused: javax.servlet.ServletException at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:765) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.MetaClass$3.doDispatch(MetaClass.java:209) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:374) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:248) at
[JIRA] (JENKINS-44132) Random JNLP Agent disconnect
Title: Message Title Ben Dean commented on JENKINS-44132 Re: Random JNLP Agent disconnect I ran into this with a Windows build agent connecting via jnlp where the connection was going through an AWS ELB that was in front of our Kubernetes cluster where the Jenkins Master is running. (Note that we're using the ELB not so much for load balancing, there is only one master after all, but just as a way to provide access to the private remoting port from outside the kube cluster.) The idle connection timeout on the ELB was set to 60 seconds and we had repo cloning that was taking longer than a minute and not producing any output during that time. Seems to be fixed by changing the ELB idle connection timeout to something higher (300 seconds or more seems okay, maybe if you have a very silent, very long build step you might need more). Also marlene cote, I don't know if you realize this or not, but you put your connection secret in the post, you should maybe change that Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-48588) Artifacts uploaded to S3 does not show up in Blue Ocean
Title: Message Title Ben Dean commented on JENKINS-48588 Re: Artifacts uploaded to S3 does not show up in Blue Ocean James Dumay, it displays them in the classic UI (although not in the same way as normal archived artifacts). The managedArtifacts option tells the step manage the artifacts in the same way normal artifacts would be managed on the Jenkins master. Here's what the documentation for that option says: When enabled, this lets Jenkins fully manage the artifacts, exactly like it does when the artifacts are published to the master. In this case, the artifacts are stored in the "jobs/[job]/[build-number]/" path in the selected bucket and prefix path. This means the following features are enabled: artifacts are finger printed and linked to the build artifacts can be downloaded directly from the build page in the S3 Artifact section artifacts are automatically deleted when the build is deleted the S3 Copy Artifact build step can be used to download artifacts from S3 automatically, helping build complex pipelines Because of that, I would expect the artifacts to show up in Blue Ocean too (either in the artifacts section or some new S3 Artifacts section like in the classic UI (although, personally I'd rather all the artifacts display in the same place, regardless of where they are archived)). This is not to dispute what you said about the extension points in Blue Ocean, but rather the idea that the S3 plugin doesn't display uploaded artifacts (because it definitely does, just not in Blue Ocean ). Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-47958) Closed branches clone again and try build
Title: Message Title Ben Dean edited a comment on JENKINS-47958 Re: Closed branches clone again and try build It is really disheartening that [~hubble1942]'s [jenkinsci/bitbucket-branch-source-plugin#106|https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/106] was closed without being merged. I get it that [~amuniz]'s concerns about being able to turn this on or off are worthwhile, but why then don't the people that us use Bitbucket and git complain about not having all their closed branches?I mean, if Jenkins itself was maintained in Bitbucket as a Mercurial repo, can you imagine having every old build for every PR branch anyone made forever? That cannot possibly be the desired default behavior. In fact, the build for Christian's branch itself is marked as an item to be deleted in the github folder on the main jenkins ci server: [https://ci.jenkins.io/job/Plugins/job/bitbucket-branch-source-plugin/view/change-requests/] PR-106 may be gone from there soon because it's closed. _That_ _seems like the desired behavior!_ Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47958) Closed branches clone again and try build
Title: Message Title Ben Dean edited a comment on JENKINS-47958 Re: Closed branches clone again and try build It is really disheartening that [~hubble1942]'s [jenkinsci/bitbucket-branch-source-plugin#106|https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/106] was closed without being merged. I get it that [~amuniz]'s concerts concerns about being able to turn this on or off are worthwhile, but why then don't the people that us Bitbucket and git complain about not having all their closed branches?I mean, if Jenkins itself was maintained in Bitbucket as a Mercurial repo, can you imagine having every old build for every PR branch anyone made forever? That cannot possibly be the desired default behavior. In fact, the build for Christian's branch itself is marked as an item to be deleted in the github folder on the main jenkins ci server: [https://ci.jenkins.io/job/Plugins/job/bitbucket-branch-source-plugin/view/change-requests/] PR-106 may be gone from there soon because it's closed. _That_ _seems like the desired behavior!_ Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47958) Closed branches clone again and try build
Title: Message Title Ben Dean commented on JENKINS-47958 Re: Closed branches clone again and try build It is really disheartening that Christian Ewald's jenkinsci/bitbucket-branch-source-plugin#106 was closed without being merged. I get it that Antonio Muñiz's concerts about being able to turn this on or off are worthwhile, but why then don't the people that us Bitbucket and git complain about not having all their closed branches? I mean, if Jenkins itself was maintained in Bitbucket as a Mercurial repo, can you imagine having every old build for every PR branch anyone made forever? That cannot possibly be the desired default behavior. In fact, the build for Christian's branch itself is marked as an item to be deleted in the github folder on the main jenkins ci server: https://ci.jenkins.io/job/Plugins/job/bitbucket-branch-source-plugin/view/change-requests/ PR-106 may be gone from there soon because it's closed. That seems like the desired behavior! Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-48588) Artifacts uploaded to S3 does not show up in Blue Ocean
Title: Message Title
Ben Dean commented on JENKINS-48588
Re: Artifacts uploaded to S3 does not show up in Blue Ocean
You can have a much more simple example than that. Try this:
node {
stage('build'){
sh 'echo foo > foo.txt'
s3Upload profileName: 'example', entries: [
[
bucket : 'fake-bucket',
selectedRegion : 'us-east-1',
sourceFile : 'foo.txt',
managedArtifacts: true,
]
]
}
}
And the place it's not showing up in Blue Ocean is here:
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-48588) Artifacts uploaded to S3 does not show up in Blue Ocean
Title: Message Title Ben Dean updated an issue Jenkins / JENKINS-48588 Artifacts uploaded to S3 does not show up in Blue Ocean Change By: Ben Dean Attachment: JENKINS_48588-blue_ocean_artifacts.png Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38417) chef-identity-plugin to support pipeline builds
Title: Message Title Ben Dean commented on JENKINS-38417 Re: chef-identity-plugin to support pipeline builds Tyler Fitch, I made a PR with some pipeline support: https://github.com/jenkinsci/chef-identity-plugin/pull/2 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38442) Support nested stages in the Pipeline Graph
Title: Message Title
Ben Dean edited a comment on JENKINS-38442
Re: Support nested stages in the Pipeline Graph
Here's a real world example of why one might have parallel stages and with some of those stages needing parallel "circles". We have an application that has these basic stages: # Clone SCM # Build # Build documentation on Windows slave (slow) # Custom static analysis tool (slow) # Multiple Test suites # Archive build artifacts and test resultsSteps 1-3 can all run in parallel and since 2 and 3 both take a long time, it's actually desirable for them to be running while we're doing all our various suites in parallel. Here's what the ideal {{Jenkinsfile}} would look like (IMHO):{code:java|title=Jenkinsfile}stage('Clone') {checkout scm}testSuites = [ 'suite1', 'suite2', 'suite3' ]parallel([buildAndTest: {stage('Build') {node('linux') {sh 'make'stash includes: 'pkg/**/*', name: 'build-artifacts'}}stage('Test') {testSteps = [:]for (suite in testSuites) {testSteps[suite] = {node('linux') { unstash 'build-artifacts' sh "run_tests $suite" stash includes: 'test_results/**/*.xml', name: "test-$suite"}}}parallel(testSteps)}},docs: {stage('Documentation') {node('windows') {bat 'build_docs.exe'}}},staticAnalysis: {stage('Static Analysis') {node('linux') {sh 'run_static_analysis'}}}])stage('Archive') {unstash 'build-artifacts'for (suite in testSuites) {unstash "test-$suite"}archive 'pkg/**/*'junit 'test_results/**/*.xml'}{code}I'm not _exactly_ sure about where that {{checkout scm}} should go with all the parallel stuff, I haven't actually run this particular thing yet. Also while writing this I wasn't really sure what to name the parallel sections at the top level, since I really want them to get their names from the nested stages.As for how this would look in the UI (only really thinking of Blue Ocean), I would want it to look how this graphviz DAG would render:{code:java|title=example.dot}digraph { graph [rankdir=LR] Clone -> Build Clone -> Documentation Clone -> "Static Analysis" Documentation -> Archive "Static Analysis" -> Archive Build -> "Test suite1" Build -> "Test suite2" Build -> "Test suite3" "Test suite1" -> Archive "Test suite2" -> Archive "Test suite3" -> Archive}{code}!example.png|thumbnail!Here's what I was thinking it might look like in Blue Ocean !pipeline_mockup.png|thumbnail!The workaround I have planned for this particular build is to have the docs and static analysis happen in other builds that I then have to wait for them to finish. Something like this:{code:java|title=Jenkinsfile}stage('Clone') {checkout scm}stage('Build') {parallel([build: {node('linux') {sh 'make'stash includes: 'pkg/**/*', name: 'build'}},docs: {build job: 'docs', wait: false},staticAnalysis: {build job: 'staticAnalysis', wait: false}])}testSuites = [ 'suite1', 'suite2', 'suite3' ]stage('Test') {testSteps = [:]for (suite in testSuites) {testSteps[suite] = {node('linux') {unstash 'build'sh "run_tests $suite"stash includes: 'test_results/**/*.xml', name: "test-$suite"}
[JIRA] (JENKINS-38442) Support nested stages in the Pipeline Graph
Title: Message Title
Ben Dean edited a comment on JENKINS-38442
Re: Support nested stages in the Pipeline Graph
Here's a real world example of why one might have parallel stages and with some of those stages needing parallel "circles". We have an application that has these basic stages: # Clone SCM # Build # Build documentation on Windows slave (slow) # Custom static analysis tool (slow) # Multiple Test suites # Archive build artifacts and test resultsSteps 1-3 can all run in parallel and since 2 and 3 both take a long time, it's actually desirable for them to be running while we're doing all our various suites in parallel. Here's what the ideal {{Jenkinsfile}} would look like (IMHO): {code: java| title=Jenkinsfile |java }stage('Clone') {checkout scm}testSuites = [ 'suite1', 'suite2', 'suite3' ]parallel([buildAndTest: {stage('Build') {node('linux') {sh 'make'stash includes: 'pkg/**/*', name: 'build-artifacts'}}stage('Test') {testSteps = [:]for (suite in testSuites) {testSteps[suite] = {node('linux') { unstash 'build-artifacts' sh "run_tests $suite" stash includes: 'test_results/**/*.xml', name: "test-$suite"}}}parallel(testSteps)}},docs: {stage('Documentation') {node('windows') {bat 'build_docs.exe'}}},staticAnalysis: {stage('Static Analysis') {node('linux') {sh 'run_static_analysis'}}}])stage('Archive') {unstash 'build-artifacts'for (suite in testSuites) {unstash "test-$suite"}archive 'pkg/**/*'junit 'test_results/**/*.xml'}{code} I'm not _exactly_ sure about where that {{checkout scm}} should go with all the parallel stuff, I haven't actually run this particular thing yet. Also while writing this I wasn't really sure what to call name the parallel sections at the top level, since I really want them to get their names from the nested stages.As for how this would look in the UI (only really thinking of Blue Ocean), I would want it to look how this graphviz DAG would render: {code: java| title=example.dot}digraph { graph [rankdir=LR] Clone -> Build Clone -> Documentation Clone -> "Static Analysis" Documentation -> Archive "Static Analysis" -> Archive Build -> "Test suite1" Build -> "Test suite2" Build -> "Test suite3" "Test suite1" -> Archive "Test suite2" -> Archive "Test suite3" -> Archive}{code} !example.png|thumbnail! Here's what I was thinking it might look like in Blue Ocean !pipeline_mockup.png|thumbnail! The workaround I have planned for this particular build is to have the docs and static analysis happen in other builds that I then have to wait for them to finish. Something like this:{code: java| title=Jenkinsfile |java }stage('Clone') {checkout scm}stage('Build') {parallel([build: {node('linux') {sh 'make'stash includes: 'pkg/**/*', name: 'build'}},docs: {build job: 'docs', wait: false},staticAnalysis: {build job: 'staticAnalysis', wait: false}])}testSuites = [ 'suite1', 'suite2', 'suite3' ]stage('Test') {testSteps = [:]for (suite in testSuites) {testSteps[suite] = {node('linux') {unstash 'build'sh "run_tests $suite"stash includes:
[JIRA] (JENKINS-38442) Support nested stages in the Pipeline Graph
Title: Message Title Ben Dean updated an issue Jenkins / JENKINS-38442 Support nested stages in the Pipeline Graph Change By: Ben Dean Attachment: pipeline_mockup.png Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38442) Support nested stages in the Pipeline Graph
Title: Message Title
Ben Dean commented on JENKINS-38442
Re: Support nested stages in the Pipeline Graph
Here's a real world example of why one might have parallel stages and with some of those stages needing parallel "circles". We have an application that has these basic stages:
Clone SCM
Build
Build documentation on Windows slave (slow)
Custom static analysis tool (slow)
Multiple Test suites
Archive build artifacts and test results
Steps 1-3 can all run in parallel and since 2 and 3 both take a long time, it's actually desirable for them to be running while we're doing all our various suites in parallel. Here's what the ideal Jenkinsfile would look like (IMHO):
Jenkinsfile
stage('Clone') {
checkout scm
}
testSuites = [ 'suite1', 'suite2', 'suite3' ]
parallel([
buildAndTest: {
stage('Build') {
node('linux') {
sh 'make'
stash includes: 'pkg/**/*', name: 'build-artifacts'
}
}
stage('Test') {
testSteps = [:]
for (suite in testSuites) {
testSteps[suite] = {
node('linux') {
unstash 'build-artifacts'
sh "run_tests $suite"
stash includes: 'test_results/**/*.xml', name: "test-$suite"
}
}
}
parallel(testSteps)
}
},
docs: {
stage('Documentation') {
node('windows') {
bat 'build_docs.exe'
}
}
},
staticAnalysis: {
stage('Static Analysis') {
node('linux') {
sh 'run_static_analysis'
}
}
}
])
stage('Archive') {
unstash 'build-artifacts'
for (suite in testSuites) {
unstash "test-$suite"
}
archive 'pkg/**/*'
junit 'test_results/**/*.xml'
}
I'm not exactly sure about where that checkout scm should go with all the parallel stuff, I haven't actually run this particular thing yet. Also while writing this I wasn't really sure what to call the parallel sections at the top level, since I really want them to get their names from the nested stages. As for how this would look in the UI (only really thinking of Blue Ocean), I would want it to look how this graphviz DAG would render:
example.dot
[JIRA] (JENKINS-38442) Support nested stages in the Pipeline Graph
Title: Message Title Ben Dean updated an issue Jenkins / JENKINS-38442 Support nested stages in the Pipeline Graph Change By: Ben Dean Attachment: example.png Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41813) bitbucket branch source folder no longer can have views
Title: Message Title
Ben Dean edited a comment on JENKINS-41813
Re: bitbucket branch source folder no longer can have views
Currently we have 821 jobs on our Jenkins server. Most of those are older freestyle jobs, some are are pipeline jobs in a BitBucket folder. We are planning on changing all of them to use pipelines and have a {{Jenkinsfile}} s committed to their repos. That pile of jobs is organized with a 15-20 views so various teams in our company can easily find the jobs they care about. Favorites _could_ solve some of that, but there are many cross-functional teams and manager types that will need to see more than just a handful of jobs. It would be nice to be able to organize them in some way (based on a job name regex, or predefined lists, etc) so the people that need to interact with many (possibly all) of those jobs can easily find what they're looking for. Coincidentally, this is one complaint we have about Blue Ocean too, favorites are fine, but when you have to scroll through pages and pages to find something, and there's no search, it can be a bit cumbersome. And for people like myself, favoriting multiple dozens of builds makes the pile of favorites unwieldy too.If the BitBucket folders made sub-folders to organize jobs by bitbucket project, that would probably be good enough.It was pretty nice to have views in these folders and was disappointing when it went away.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email
[JIRA] (JENKINS-41813) bitbucket branch source folder no longer can have views
Title: Message Title
Ben Dean commented on JENKINS-41813
Re: bitbucket branch source folder no longer can have views
Currently we have 821 jobs on our Jenkins server. Most of those are older freestyle jobs, some are are pipeline jobs in a BitBucket folder. We are planning on changing all of them to use pipelines and have {{Jenkinsfile}}s committed to their repos. That pile of jobs is organized with a 15-20 views so various teams in our company can easily find the jobs they care about. Favorites could solve some of that, but there are many cross-functional teams and manager types that will need to see more than just a handful of jobs. It would be nice to be able to organize them in some way (based on a job name regex, or predefined lists, etc) so the people that need to interact with many (possibly all) of those jobs can easily find what they're looking for. Coincidentally, this is one complaint we have about Blue Ocean too, favorites are fine, but when you have to scroll through pages and pages to find something, and there's no search, it can be a bit cumbersome. And for people like myself, favoriting multiple dozens of builds makes the pile of favorites unwieldy too. If the BitBucket folders made sub-folders to organize jobs by bitbucket project, that would probably be good enough. It was pretty nice to have views in these folders and was disappointing when it went away.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[JIRA] (JENKINS-41813) bitbucket branch source folder no longer can have views
Title: Message Title Ben Dean created an issue Jenkins / JENKINS-41813 bitbucket branch source folder no longer can have views Issue Type: Bug Assignee: Antonio Muñiz Components: bitbucket-branch-source-plugin Created: 2017/Feb/07 3:41 PM Environment: Jenkins 2.45 cloudbees-bitbucket-branch-source 2.0.2 workflow-multibranch 2.12 scm-api 2.0.2 Priority: Major Reporter: Ben Dean Previous plugin versions that worked: cloudbees-bitbucket-branch-source 1.9 workflow-multibranch 2.9.2 scm-api 1.3 The basic problem is that I used to be able to add views (List view, Nested view, etc) to the bitbucket folder. Now that's gone and the existing views I had are also go. when I try to go to https://build.foo/job/bb_org/newView I get the normal create a view page, but when I create that view I get a 404 on https://build.foo/job/bb_org/view/some_view/configure. Also all the view creating links are gone from the UI. This is pretty bad if your Bitbucket org has hundreds of repos and you expect to use a single bitbucket folder and views inside that folder to organize the jobs. Note that standard organizational folders still have views, just not the bitbucket one.
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title Ben Dean commented on JENKINS-40734 Re: Shell step cannot use environment variables that contain $$ Yes, that would be answer for withCredentials. But it would make the pipelines behave a bit differently than the envinject and credentials-binding plugins which do not escape $ in passwords. Maybe they should be fixed too. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title Ben Dean commented on JENKINS-40734 Re: Shell step cannot use environment variables that contain $$ I just tested how this would work with the envinject plugin in a freestyle job and it also replaces the $$ with a single $ in a password. Here's the config.xml false "hudson.scm.NullSCM"/> true false false false false "envinject@1.93.1"> DEF=$ABC:456 echo Password: "$PASSWORD" echo ABC: $ABC echo DEF: $DEF "envinject@1.93.1"> ABC=123 false "envinject@1.93.1"> false true PASSWORD kGFMn/q9EkRqYVDkmuj/tQMlyX/YuesVmq7bZqTGuBs= that outputs: Started by user admin [EnvInject] - Loading node environment variables. Building in workspace /var/jenkins_home/workspace/test [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties content ABC=123 [EnvInject] - Variables injected successfully. [EnvInject] - Mask passwords that will be passed as build parameters. [EnvInject] - Injecting environment variables from a build step. [EnvInject] - Injecting as environment variables the properties content DEF=123:456 [EnvInject] - Variables injected successfully. [test] $ /bin/sh -xe /tmp/hudson7658063203774926176.sh + echo Password: bar$baz Password: bar$baz + echo ABC: 123 ABC: 123 + echo DEF: 123:456 DEF: 123:456 Finished: SUCCESS I also tried this using the plain-credentials and credentials-binding plugins in a freestyle job. Same thing, $$ in the password gets replaced with $. Here's that config.xml false "hudson.scm.NullSCM"/> true false false false false echo Username: "$USERNAME" Password: "$PASSWORD" "credentials-binding@1.10"> foo USERNAME PASSWORD which outputs: Started by user admin [EnvInject] - Loading node environment variables. Building in workspace /var/jenkins_home/workspace/test2 [test2] $ /bin/sh -xe /tmp/hudson6763543920526348076.sh + echo Username: Password: bar$baz Username: Password: bar$baz Finished: SUCCESS So I guess durable-task was at least consistent with how things work in the older plugins and freestyle jobs. I'm not really sure what the answer is for
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title
Ben Dean edited a comment on JENKINS-40734
Re: Shell step cannot use environment variables that contain $$
The environment variables are being set by {{withCredentials}}. If you look at the original description on this issue, you'll find complete reproduction steps. The scenario where I was running into this bug was with credentials, but [~jglick] said that it would be a problem with any environment variables. A {{Jenkinsfile}} like this would also not have the correct values for the environment variables:{code:none}node{withEnv(['USERNAME=foo', 'PASSWORD=bar$$baz']) {echo "Username: ${env.USERNAME}"echo "Password: ${env.PASSWORD}"sh 'echo Username: "$USERNAME", Password: "$PASSWORD"'}}{code}which outputs: {code:none}Started by user admin[Pipeline] nodeRunning on master in /var/jenkins_home/workspace/test[Pipeline] {[Pipeline] withEnv[Pipeline] {[Pipeline] echoUsername: foo[Pipeline] echoPassword: bar$$baz[Pipeline] sh[test] Running shell script+ echo Username: foo, Password: bar$bazUsername: foo, Password: bar$baz[Pipeline] }[Pipeline] // withEnv[Pipeline] }[Pipeline] // node[Pipeline] End of PipelineFinished: SUCCESS{code}note that the environment variables are correct on the {{env}} global variable, but they are wrong in the shell step. That output is using durable-task v1.12
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title
Ben Dean commented on JENKINS-40734
Re: Shell step cannot use environment variables that contain $$
The environment variables are being set by withCredentials. If you look at the original description on this issue, you'll find complete reproduction steps. The scenario where I was running into this bug was with credentials, but Jesse Glick said that it would be a problem with any environment variables. A Jenkinsfile like this would also not have the correct values for the environment variables:
node{
withEnv(['USERNAME=foo', 'PASSWORD=bar$$baz']) {
echo "Username: ${env.USERNAME}"
echo "Password: ${env.PASSWORD}"
sh 'echo Username: "$USERNAME", Password: "$PASSWORD"'
}
}
which outputs:
Started by user admin
[Pipeline] node
Running on master in /var/jenkins_home/workspace/test
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] echo
Username: foo
[Pipeline] echo
Password: bar$$baz
[Pipeline] sh
[test] Running shell script
+ echo Username: foo, Password: bar$baz
Username: foo, Password: bar$baz
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
note that the environment variables are correct on the env global variable, but they are wrong in the shell step.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title Ben Dean commented on JENKINS-40734 Re: Shell step cannot use environment variables that contain $$ John Ericson, what aforementioned double-quote solution? None of the things Jesse Glick mentioned as corrections to my Jenkinsfile actually worked. The problem is that if the password or environment variable has a double $ (such as "bar$$baz"), the durable task plugin is changing that to a single $ in the actual environment variable set for the sh step. I don't know how any change in quoting will fix that. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title Ben Dean commented on JENKINS-40734 Re: Shell step cannot use environment variables that contain $$ Jesse Glick, the shell script you suggested doesn't work either. Putting single quotes around the environment variables will cause bash (or sh, or dash, or whatever the shell is) to not evaluate them and the output of the build is: + echo Username: $USERNAME, Password: $PASSWORD Username: $USERNAME, Password: $PASSWORD If I change those to double quotes it will evaluate them, but it will have the same problem it had before sh ''' echo Username: "$USERNAME", Password: "$PASSWORD" ''' outputs: + echo Username: , Password: bar$baz Username: , Password: bar$baz And don't think to much about the echo command in the shell either. In the real place where I'm running into this problem, I'm passing the username and password to some CLI: sh ''' some-cli do stuff "$USERNAME" "$PASSWORD" ''' and they have to be double quoted there so bash will correctly pass the args to the command line if they contain spaces or other characters that have to be quoted. Add Comment
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title Ben Dean reopened an issue Jesse Glick, the shell script you suggested doesn't work either. Putting single quotes around the environment variables will cause bash (or sh, or dash, or whatever the shell is) to not evaluate them and the output of the build is: + echo Username: $USERNAME, Password: $PASSWORD Username: $USERNAME, Password: $PASSWORD If I change those to double quotes it will evaluate them, but it will have the same problem it had before sh ''' echo Username: "$USERNAME", Password: "$PASSWORD" ''' outputs: + echo Username: , Password: bar$baz Username: , Password: bar$baz And don't think to much about the echo command in the shell either. In the real place where I'm running into this problem, I'm passing the username and password to some CLI: sh ''' some-cli do stuff "$USERNAME" "$PASSWORD" ''' and they have to be double quoted there so bash will correctly pass the args to the command line if they contain spaces or other characters that have to be quoted. Jenkins / JENKINS-40734 Shell step cannot use environment variables that contain $$ Change By: Ben Dean Resolution: Not A Defect Status: Resolved Reopened
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title
Ben Dean updated an issue
Jenkins / JENKINS-40734
Shell step cannot use environment variables that contain $$
Change By:
Ben Dean
Comment:
[~jglick], the shell script you suggested doesn't work either. Putting single quotes around the environment variables will cause bash (or sh, or dash, or whatever the shell is) to not evaluate them and the output of the build is:{code:none}+ echo Username: $USERNAME, Password: $PASSWORDUsername: $USERNAME, Password: $PASSWORD{code}If I change those to double quotes it will evaluate them, but it will have the same problem it had before{code:none}sh '''echo Username: "$USERNAME", Password: "$PASSWORD"'''{code}outputs: {code:none}+ echo Username: , Password: bar$bazUsername: , Password: bar$baz{code}And don't think to much about the {{echo}} command in the shell either. In the real place where I'm running into this problem, I'm passing the username and password to some CLI:{code:none}sh '''some-cli do stuff "$USERNAME" "$PASSWORD"'''{code}and they have to be double quoted there so bash will correctly pass the args to the command line if they contain spaces or other characters that have to be quoted.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-40734) Shell step cannot use environment variables that contain $$
Title: Message Title
Ben Dean created an issue
Jenkins / JENKINS-40734
Shell step cannot use environment variables that contain $$
Issue Type:
Bug
Assignee:
Unassigned
Components:
durable-task-plugin, pipeline, workflow-durable-task-step-plugin
Created:
2016/Dec/30 2:59 PM
Environment:
CentOS 6.8 Jenkins 2.38 durable-task-plugin 1.12 workflow-aggregator (pipeline) 2.4 and all its dependencies: workflow-cps (version:2.17) workflow-support (version:2.5) workflow-basic-steps (version:2.1) pipeline-input-step (version:2.1) pipeline-milestone-step (version:1.0) pipeline-build-step (version:2.2) pipeline-stage-view (version:2.0) workflow-multibranch (version:2.8) workflow-durable-task-step (version:2.4) workflow-api (version:2.3) pipeline-stage-step (version:2.2) workflow-scm-step (version:2.2) workflow-cps-global-lib (version:2.3) workflow-step-api (version:2.3) workflow-job (version:2.6)
Labels:
pipeline credentials environment-variables shell
Priority:
Minor
Reporter:
Ben Dean
When I run a Jenkinsfile that has a sh step that uses an environment variable (such as a password) that has two $$ in a row, they get replaced with one $. Here's the steps to reproduce: 1. Make a global credential id "foo", username "foo", password "bar$$baz" 2. Use this Jenkinsfile:
node('linux') {
withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId: 'foo',
[JIRA] (JENKINS-27421) Unserializable iterator & entry classes from Java Collections
Title: Message Title Ben Dean commented on JENKINS-27421 Re: Unserializable iterator & entry classes from Java Collections Jesse Glick, the reason I mentioned ArrayList and my safeArray method is that based on the earlier entries method you mentioned, it seems like .collect is fine and it returns an ArrayList. Also I actually tried my safeArray thing and it worked to iterate over that in CPS code. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-27421) Unserializable iterator & entry classes from Java Collections
Title: Message Title
Ben Dean commented on JENKINS-27421
Re: Unserializable iterator & entry classes from Java Collections
Jesse Glick, is there going to be a better way to do that? Because it seems a little silly to have my Jenkinsfile scripts littered with stuff like
@NonCPS def safeArray(c) {
c.collect { v -> v }
}
// ...
def someMap = [a: 1, b:2]
for (def thing in safeArray(someMap.values())) {
echo "do something with $thing"
}
in fact, why bother with .collect, it just needs to be an ArrayList
def someMap = [a: 1, b:2]
for (def thing in new ArrayList(someMap.values())) {
echo "do something with $thing"
}
which needs script security approval, But that's basically what .collect is doing. I guess I'm not seeing the point of us having the have a bunch of helper methods to turn all Collection into ArrayList.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving
[JIRA] (JENKINS-38417) Support pipeline builds
Title: Message Title
Ben Dean created an issue
Jenkins / JENKINS-38417
Support pipeline builds
Issue Type:
New Feature
Assignee:
Tyler Fitch
Components:
chef-identity-plugin
Created:
2016/Sep/21 1:40 PM
Environment:
Jenkins 2.x
Priority:
Minor
Reporter:
Ben Dean
It would be great if the chef identity plugin would support build pipelines. Either by changing ChefIdentityBuildWrapper to extend SimpleBuildWrapper or better yet, by adding some sort of withChefIdentity method, similar to the withCredentials or withEnv. Maybe like this?
stage("upload") {
withChefIdentity("my_org") {
sh "knife cookbook upload foo -o .. -c .chef/knife.rb"
}
}
Add Comment
[JIRA] (JENKINS-38417) chef-identity-plugin to support pipeline builds
Title: Message Title Ben Dean updated an issue Jenkins / JENKINS-38417 chef-identity-plugin to support pipeline builds Change By: Ben Dean Summary: Support chef-identity-plugin to support pipeline builds Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-38390) Timestamp background color white
Title: Message Title Ben Dean created an issue Jenkins / JENKINS-38390 Timestamp background color white Issue Type: Bug Assignee: Steven G Brown Attachments: console output.png Components: ansicolor-plugin, simple-theme-plugin, timestamper-plugin Created: 2016/Sep/20 9:34 PM Environment: Jenkins 2.20 timestamper-plugin 1.8.6 ansicolor-plugin 0.4.2 simple-theme-plugin 0.3 material theme 1.3.1 Priority: Minor Reporter: Ben Dean This is the theme URL I'm using: https://jenkins-contrib-themes.github.io/jenkins-material-theme/dist/material-light-blue.css Then I have a build with the timestamp and ansi color wrappers and one shell step that does this: #!/bin/bash echo "This looks terrible" echo -e "\e[31m This is red\e[0m" echo -e "\e[32m This doesn't reset" echo "The end" The attached screenshot is the build output. It does not do this with timestamper 1.8.4 (which we had previously). This seems to be related to JENKINS-34019
[JIRA] (JENKINS-23762) Adding a mixin class to Job leaks memory from every DSL run
Title: Message Title Ben Dean commented on JENKINS-23762 Re: Adding a mixin class to Job leaks memory from every DSL run So if the CloudBees people wanted to make their cloudbees-folder plugin (or more specifically the branch-api plugin, which is where the jenkins.branch.OrganizationFolder class comes from), support the jobdsl, they wouldn't be able to add a new top level kind of thing? It's very similar to the MultibranchWorkflowJob but has a few different elements in the xml (and different root node). If it was going to be in the job-dsl plugin itself, it'd probably be a subclass of MultibranchWorkflowJob or they'd both subclass some AbstractMultibranchWorkflowJob or whatever, but I don't see any way that plugin developers can add job dsl methods for things like that. If that makes any sense. Also, I realize this is getting further away from memory-leaking monkey patches, just trying to figure out what "correct" way to do this stuff. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-23762) Adding a mixin class to Job leaks memory from every DSL run
Title: Message Title
Ben Dean commented on JENKINS-23762
Re: Adding a mixin class to Job leaks memory from every DSL run
And if it's a new kind of thing? As in something that cannot currently be created with and of the jobs, views, folders, etc. Specifically, we have methods to add the CloudBees Bitbucket Source Folder stuff. It's a new class that is a subclass of Folder but in order to make it
class BitbucketFolder extends Folder {
// ... lots of stuff
}
JobParent.metaClass.bitbucketFolder = { String name, Closure closure ->
processItem(name, BitbucketFolder, closure)
}
I don't think I can call processItem from a job dsl script since it's protected
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-23762) Adding a mixin class to Job leaks memory from every DSL run
Title: Message Title
Ben Dean commented on JENKINS-23762
Re: Adding a mixin class to Job leaks memory from every DSL run
@daspilker, I am running into an OutOfMemory error with Jenkins 2.18, job-dsl plugin 1.50 and I suspect it is related to this issue. I'm not using mixins but I am doing a lot of monkey-patching. Here's a path to a GC root for a groovy closure that is almost certainly something from one of my job dsl scripts:
this - value: groovy.lang.GroovyClassLoader$InnerLoader #12
<- - class: Script1$_run_closure1, value: groovy.lang.GroovyClassLoader$InnerLoader #12
<- klazz - class: org.codehaus.groovy.reflection.ClassInfo, value: Script1$_run_closure1 class Script1$_run_closure1
<- value - class: org.codehaus.groovy.reflection.GroovyClassValuePreJava7$EntryWithValue, value: org.codehaus.groovy.reflection.ClassInfo #62
<- [6656] - class: java.lang.Object[], value: org.codehaus.groovy.reflection.GroovyClassValuePreJava7$EntryWithValue #62
<- table - class: org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Segment, value: java.lang.Object[] #39966
<- [0] - class: org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment[], value: org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Segment #16
<- segments - class: org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Map, value: org.codehaus.groovy.util.AbstractConcurrentMapBase$Segment[] #1
<- map - class: org.codehaus.groovy.reflection.GroovyClassValuePreJava7, value: org.codehaus.groovy.reflection.GroovyClassValuePreJava7$GroovyClassValuePreJava7Map #1
<- globalClassValue - class: org.codehaus.groovy.reflection.ClassInfo, value: org.codehaus.groovy.reflection.GroovyClassValuePreJava7 #1
<- (Java frame) - class: org.codehaus.groovy.reflection.ClassInfo, value: org.codehaus.groovy.reflection.ClassInfo class ClassInfo
Most of the things I'm adding methods to are Context classes so I could change those to use the newer DslExtensionPoint stuff, rather than monkey-patching new methods onto those classes. In fact, you actually deleted the wiki page with the monkey-patching examples. But as far as I can tell, there's no way, other than monkey-patching, to add methods to things like JobParent. I need to do this so I can add new kinds of jobs or folders or whatever, top level dsl methods. Do you have a recommendation for how to do that? Our dsl script looks something like this (more or less)
JobParent.metaClass.dockerJob = { String name, Closure closure ->
DockerJobContext context = new DockerJobContext()
ContextHelper.executeInContext(closure, context)
job("docker/$name") {
steps {
shell("docker pull $context.docker.baseImage")
}
// lots of other steps, wrappers, publishers, etc
}
}
dockerJob('docker/foo') {
docker {
baseImage "ruby:2.1-onbuild"
}
}
That's obviously a much shortened version of what we're doing, but does that
[JIRA] (JENKINS-37450) Cannot create nestedView with job-dsl 1.49
Title: Message Title
Ben Dean updated an issue
Jenkins / JENKINS-37450
Cannot create nestedView with job-dsl 1.49
Change By:
Ben Dean
This all worked fine earlier today when I had 1.48. Once I upgraded to 1.49 I started getting this error:{code}11:40:52 com.thoughtworks.xstream.mapper.CannotResolveClassException: hudson.plugins.nested__view.NestedView11:40:52 at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:79)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:55)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:79)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:74)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.SecurityMapper.realClass(SecurityMapper.java:71)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at hudson.util.XStream2$CompatibilityMapper.realClass(XStream2.java:282)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at hudson.util.xstream.MapperDelegate.realClass(MapperDelegate.java:43)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:48)11:40:52 at
[JIRA] (JENKINS-37450) Cannot create nestedView with job-dsl 1.49
Title: Message Title
Ben Dean updated an issue
Jenkins / JENKINS-37450
Cannot create nestedView with job-dsl 1.49
Change By:
Ben Dean
This all worked fine earlier today when I had 1.48. Once I upgraded to 1.49 I started getting this error:{code}11:40:52 com.thoughtworks.xstream.mapper.CannotResolveClassException: hudson.plugins.nested__view.NestedView11:40:52 at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:79)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:55)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:79)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.ArrayMapper.realClass(ArrayMapper.java:74)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.SecurityMapper.realClass(SecurityMapper.java:71)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at hudson.util.XStream2$CompatibilityMapper.realClass(XStream2.java:282)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at hudson.util.xstream.MapperDelegate.realClass(MapperDelegate.java:43)11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30)11:40:52 at com.thoughtworks.xstream.mapper.CachingMapper.realClass(CachingMapper.java:48)11:40:52 at
[JIRA] (JENKINS-37450) Cannot create nestedView with job-dsl 1.49
Title: Message Title Ben Dean created an issue Jenkins / JENKINS-37450 Cannot create nestedView with job-dsl 1.49 Issue Type: Bug Assignee: Daniel Spilker Components: job-dsl-plugin, nested-view-plugin Created: 2016/Aug/16 7:03 PM Environment: Jenkins 2.18 job-dsl 1.49 nested-view 1.14 Priority: Major Reporter: Ben Dean This all worked fine earlier today when I had 1.48. Once I upgraded to 1.49 I started getting this error: 11:40:52 com.thoughtworks.xstream.mapper.CannotResolveClassException: hudson.plugins.nested__view.NestedView 11:40:52 at com.thoughtworks.xstream.mapper.DefaultMapper.realClass(DefaultMapper.java:79) 11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) 11:40:52 at com.thoughtworks.xstream.mapper.DynamicProxyMapper.realClass(DynamicProxyMapper.java:55) 11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) 11:40:52 at com.thoughtworks.xstream.mapper.PackageAliasingMapper.realClass(PackageAliasingMapper.java:88) 11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) 11:40:52 at com.thoughtworks.xstream.mapper.ClassAliasingMapper.realClass(ClassAliasingMapper.java:79) 11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) 11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) 11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) 11:40:52 at com.thoughtworks.xstream.mapper.MapperWrapper.realClass(MapperWrapper.java:30) 11:40:52 at
[JIRA] [cucumber-testresult-plugin] (JENKINS-35471) pom.xml dependency on org.jenkins-ci.plugins:junit version that does not exist
Title: Message Title
Ben Dean updated an issue
Jenkins / JENKINS-35471
pom.xml dependency on org.jenkins-ci.plugins:junit version that does not exist
Change By:
Ben Dean
The {{ pom.xml }} depends on { { code:xml} org.jenkins-ci.plugins junit 1.2-beta-3 {code } } And the {{ MANIFEST.MF }} in the {{ cucumber-testresult-plugin.hpi }} also has a dependency listed for junit 1.2.-beta-3. However, that version of the junit plugin does not exist: http://updates.jenkins-ci.org/download/plugins/junit/This isn't a big deal and won't really affect anyone installing from the Jenkins UI, but if someone is looking at dependencies, such as those listed in http://updates.jenkins-ci.org/update-center.json, or in the {{ MANIFEST.MF }} , or the {{ pom.xml }} , they'll have trouble finding one to satisfy that junit 1.2-beta-3
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [cucumber-testresult-plugin] (JENKINS-35471) pom.xml dependency on org.jenkins-ci.plugins:junit version that does not exist
Title: Message Title
Ben Dean created an issue
Jenkins / JENKINS-35471
pom.xml dependency on org.jenkins-ci.plugins:junit version that does not exist
Issue Type:
Bug
Assignee:
James Nord
Components:
cucumber-testresult-plugin
Created:
2016/Jun/08 1:03 PM
Environment:
centos 6.7 jenkins 2.8 cucumber-testresult-plugin 0.8.2
Priority:
Minor
Reporter:
Ben Dean
The pom.xml depends on
{{ org.jenkins-ci.plugins junit 1.2-beta-3 }}
And the MANIFEST.MF in the cucumber-testresult-plugin.hpi also has a dependency listed for junit 1.2.-beta-3. However, that version of the junit plugin does not exist: http://updates.jenkins-ci.org/download/plugins/junit/
This isn't a big deal and won't really affect anyone installing from the Jenkins UI, but if someone is looking at dependencies, such as those listed in http://updates.jenkins-ci.org/update-center.json, or in the MANIFEST.MF, or the pom.xml, they'll have trouble finding one to satisfy that junit 1.2-beta-3
[JIRA] [copyartifact] (JENKINS-25155) NPE during Copy Artifact in Promotion
Ben Dean created JENKINS-25155 NPE during Copy Artifact in Promotion Issue Type: Bug Assignee: Unassigned Components: copyartifact, promoted-builds Created: 14/Oct/14 9:04 PM Description: Copy Artifact doesn't seem to work inside promotions. For the normal build steps it is fine and copies without problem when it's in a promotion I get this: java.lang.NullPointerException at hudson.plugins.copyartifact.CopyArtifact$EnvAction.add(CopyArtifact.java:512) at hudson.plugins.copyartifact.CopyArtifact$EnvAction.access$500(CopyArtifact.java:502) at hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:296) at hudson.plugins.promoted_builds.Promotion$RunnerImpl.build(Promotion.java:282) at hudson.plugins.promoted_builds.Promotion$RunnerImpl.doRun(Promotion.java:224) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533) at hudson.model.Run.execute(Run.java:1754) at hudson.model.Run.run(Run.java:1692) at hudson.plugins.promoted_builds.Promotion.run(Promotion.java:174) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) The configuration for the promotion is simple: hudson.plugins.promoted__builds.PromotionProcess plugin="promoted-builds@2.19" actions/ keepDependenciesfalse/keepDependencies properties/ scm class="hudson.scm.NullSCM"/ canRoamtrue/canRoam disabledfalse/disabled blockBuildWhenDownstreamBuildingfalse/blockBuildWhenDownstreamBuilding blockBuildWhenUpstreamBuildingfalse/blockBuildWhenUpstreamBuilding triggers/ concurrentBuildfalse/concurrentBuild conditions/ iconstar-gold/icon buildSteps hudson.plugins.copyartifact.CopyArtifact plugin="copyartifact@1.32" projectsome-job/project filter**/*/filter target/ excludes/ selector class="hudson.plugins.copyartifact.StatusBuildSelector"/ flattentrue/flatten doNotFingerprintArtifactsfalse/doNotFingerprintArtifacts /hudson.plugins.copyartifact.CopyArtifact /buildSteps /hudson.plugins.promoted__builds.PromotionProcess When I downgraded those two plugins (because I figured the culprit was either Copy Artifact or Promoted Builds) to these versions everything worked again: Copy Artifact Plugin 1.30 Promoted Builds Plugin 2.17 Environment: Jenkins 1.584 Copy Artifact Plugin 1.32 Promoted Builds Plugin 2.19 Master/Slave OS: CentOS 6.5 Project: Jenkins Labels: npe plugin Priority: Major Reporter: Ben Dean This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-20682) Starting Jenkins with defined --webroot or JETTY_HOME not working.
Ben Dean commented on JENKINS-20682 Starting Jenkins with defined --webroot or JETTY_HOME not working. This is a big deal. If the operating system is set up to run tmpwatch with cron (our CentOS box is this way), files will start to get deleted from that /tmp/jetty-... folder and then Jenkins won't work correctly. Usually this is just icons and other images being broken in the UI, but sometimes it could be important jars missing. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-14329) SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild)
Ben Dean updated JENKINS-14329 SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild) Updated environment to include Jenkins version 1.475, I tested and the bug still exists there (same versions of the two plugins). Change By: Ben Dean (25/Jul/12 4:32 PM) Environment: OS:WindowsServer2008R2Jenkins:1.461,1.470,1.473 ,1.475 JenkinsParameterizedTriggerplugin:2.15SCMSyncConfigurationPlugin:0.0.5 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14329) Trigger parameterized build and block as build step never returns (waiting for the completion of OtherBuild)
Ben Dean
updated JENKINS-14329
Trigger parameterized build and block as build step never returns (waiting for the completion of OtherBuild)
Editing description and components to reflect the cause of the problem being the SCM Sync Configuration Plugin.
Change By:
Ben Dean
(06/Jul/12 3:03 PM)
Environment:
OS:WindowsServer2008R2Jenkins:1.
461,1.470,1.
473
Jenkins
Parameterized
Build
Triggerplugin:2.15
SCMSyncConfigurationPlugin:0.0.5
Description:
VerysimplebuildswhereBuild{{A}}triggersbuild{{B}}andwaitsforcompletionresultsinthefollowingoutput:{noformat}Startedbyuseranonymous
[EnvInject]-Loadingnodeenvironmentvariables.
BuildinginworkspaceC:\JW\AWaitingforthecompletionofB{noformat}Andevenafter{{B}}hascompleted,{{A}}neverfinishes.Configurationfilesforbuilds{{A}}and{{B}}areattached.
Wedonthave
Itested
this
problem
in
all
the
lastversion
versions
ofJenkins
wewereusing,{{1
mentionedintheEnvironmentsectionaboveanditwaspresentinallofthem
.
461}}
TheproblemseemstobecausedbytheSCMSyncConfigurationPlugin
.I
dontknowif
tested
it
ssomethingnewin
withafreshinstallofJenkins
{{1.473}}
andonlythetwopluginsforSCMSyncandParameterizedTriggerenabledandthebugwaspresent
.
DisablingSCMSynccausedittogoaway.
Component/s:
scm-sync-configuration
Component/s:
plugin
Component/s:
core
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14329) SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild)
Ben Dean updated JENKINS-14329 SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (stuck on waiting for the completion of OtherBuild) fixing hilarious typo Change By: Ben Dean (06/Jul/12 3:06 PM) Summary: SCMSyncConfigurationpluginconflictswithParameterizedTriggerplugin.( suck stuck onwaitingforthecompletionofOtherBuild) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14329) SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (suck on waiting for the completion of OtherBuild)
Ben Dean updated JENKINS-14329 SCM Sync Configuration plugin conflicts with Parameterized Trigger plugin. (suck on waiting for the completion of OtherBuild) changing title to more accurately describe the problem Change By: Ben Dean (06/Jul/12 3:05 PM) Summary: SCMSyncConfigurationpluginconflictswithParameterized Trigger parameterizedbuildandblockasbuildstepneverreturns plugin. ( suckon waitingforthecompletionofOtherBuild) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14329) Trigger parameterized build and block as build step never returns (waiting for the completion of OtherBuild)
Ben Dean updated JENKINS-14329 Trigger parameterized build and block as build step never returns (waiting for the completion of OtherBuild) Change By: Ben Dean (05/Jul/12 10:18 PM) Component/s: core Component/s: plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14329) Trigger parameterized build and block as build step never returns (waiting for the completion of OtherBuild)
Ben Dean created JENKINS-14329 Trigger parameterized build and block as build step never returns (waiting for the completion of OtherBuild) Issue Type: Bug Affects Versions: current Assignee: huybrechts Attachments: A.config.xml, B.config.xml Components: parameterized-trigger Created: 05/Jul/12 10:17 PM Description: Very simple builds where Build A triggers build B and waits for completion results in the following output: Started by user anonymous [EnvInject] - Loading node environment variables. Building in workspace C:\JW\A Waiting for the completion of B And even after B has completed, A never finishes. Configuration files for builds A and B are attached. We don't have this problem in the last version of Jenkins we were using, 1.461. I don't know if it's something new in 1.473. Environment: OS: Windows Server 2008 R2 Jenkins: 1.473 Parameterized Build Trigger plugin: 2.15 Project: Jenkins Priority: Major Reporter: Ben Dean This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10342) Build triggered by promotion fails
[
https://issues.jenkins-ci.org/browse/JENKINS-10342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162352#comment-162352
]
Ben Dean commented on JENKINS-10342:
Having same issue with:
* Jenkins: 1.461
* Downstream Build View: 1.7
* Promoted builds: 2.5
Stacktrace:
{code}
java.lang.NullPointerException
at
org.jvnet.hudson.plugins.DownstreamBuildViewUpdateListener.onStarted(DownstreamBuildViewUpdateListener.java:85)
at
org.jvnet.hudson.plugins.DownstreamBuildViewUpdateListener.onStarted(DownstreamBuildViewUpdateListener.java:46)
at hudson.model.listeners.RunListener.fireStarted(RunListener.java:188)
at hudson.model.Run.run(Run.java:1429)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
{code}
Build triggered by promotion fails
--
Key: JENKINS-10342
URL: https://issues.jenkins-ci.org/browse/JENKINS-10342
Project: Jenkins
Issue Type: Bug
Components: downstream-buildview
Affects Versions: current
Environment: Jenkins version = 1.420
Promoted builds plugin version = 2.2
Reporter: Roy Truelove
Attachments: PromotionConfig.jpg
I created two bare bones test projects to replicate:
# *BUG TEST - promoter* - Does nothing, but has a promotion which must be
manually approved, and which triggers a parametrized build of another project
(See screenshot)
# *BUG TEST - downstream* - Does nothing at all.
When I promote the first project, I expect the second to run. Instead I get:
{code}
Started by upstream project BUG TEST -
promoter/promotion/GoldStarPromotions build number 5
FATAL: null
java.lang.NullPointerException
at
org.jvnet.hudson.plugins.DownstreamBuildViewUpdateListener.onStarted(DownstreamBuildViewUpdateListener.java:85)
at
org.jvnet.hudson.plugins.DownstreamBuildViewUpdateListener.onStarted(DownstreamBuildViewUpdateListener.java:46)
at hudson.model.listeners.RunListener.fireStarted(RunListener.java:188)
at hudson.model.Run.run(Run.java:1371)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)
{code}
If any further information would be helpful please let me know.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
