[JIRA] (JENKINS-52751) Exceptions when failure-cause plugin is installed but does not identify failure causes
Title: Message Title Bertrand Roussel commented on JENKINS-52751 Re: Exceptions when failure-cause plugin is installed but does not identify failure causes Could we get a new release for this plugin? It seems that PR #22 was merged some time ago, so a build from the trunk would likely have that fixed, but the latest release is 1.1.3 and does not include that fix. cc: Tobias Getrost Luca Domenico Milanesio 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.192647.1532606938000.8856.1580386260200%40Atlassian.JIRA.
[JIRA] (JENKINS-55137) No branch name in logs from parallel branches anymore?
Title: Message Title
Bertrand Roussel updated an issue
Jenkins / JENKINS-55137
No branch name in logs from parallel branches anymore?
Change By:
Bertrand Roussel
Before with parallel(), we used to have the branch name in the logs as a prefix for each log message from that branch.Now it seems that there is a mechanism to show/hide based on each branch.With the code:{code}builds = [:]builds['foo'] = { echo "message 1" }builds['bar'] = { echo "message 2" }parallel(builds){code}'Before':{noformat}[Pipeline] parallel[Pipeline] [foo] { (Branch: foo)[Pipeline] [bar] { (Branch: bar)[Pipeline] [foo] echo[foo] message 1[Pipeline] [foo] }[Pipeline] [bar] echo[bar] message 2[Pipeline] [bar] }[Pipeline] // parallel[Pipeline] End of PipelineFinished: SUCCESS{noformat}Now:{noformat} {noformat} [Pipeline] parallel[Pipeline] { (Branch: foo)[Pipeline] { (Branch: bar)[Pipeline] echomessage 1[Pipeline] }[Pipeline] echomessage 2[Pipeline] }[Pipeline] // parallel[Pipeline] End of PipelineFinished: SUCCESS {noformat}
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.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55137) No branch name in logs from parallel branches anymore?
Title: Message Title
Bertrand Roussel created an issue
Jenkins / JENKINS-55137
No branch name in logs from parallel branches anymore?
Issue Type:
Bug
Assignee:
Unassigned
Components:
workflow-cps-plugin
Created:
2018-12-12 08:00
Priority:
Major
Reporter:
Bertrand Roussel
Before with parallel(), we used to have the branch name in the logs as a prefix for each log message from that branch. Now it seems that there is a mechanism to show/hide based on each branch. With the code:
builds = [:]
builds['foo'] = { echo "message 1" }
builds['bar'] = { echo "message 2" }
parallel(builds)
'Before':
[Pipeline] parallel
[Pipeline] [foo] { (Branch: foo)
[Pipeline] [bar] { (Branch: bar)
[Pipeline] [foo] echo
[foo] message 1
[Pipeline] [foo] }
[Pipeline] [bar] echo
[bar] message 2
[Pipeline] [bar] }
[Pipeline] // parallel
[Pipeline] End of Pipeline
Finished: SUCCESS
Now:
[Pipeline] parallel [Pipeline] { (Branch: foo) [Pipeline] { (Branch: bar) [Pipeline] echo message 1 [Pipeline] } [Pipeline] echo message 2 [Pipeline] } [Pipeline] // parallel [Pipeline] End of Pipeline Finished: SUCCESS
[JIRA] (JENKINS-55125) NPE in splitCauses
Title: Message Title Bertrand Roussel updated an issue Jenkins / JENKINS-55125 NPE in splitCauses Change By: Bertrand Roussel Priority: Major Blocker 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55110) BFA 1.21.0 fails to create a failure cause / scan jobs
Title: Message Title
Bertrand Roussel updated an issue
Jenkins / JENKINS-55110
BFA 1.21.0 fails to create a failure cause / scan jobs
Change By:
Bertrand Roussel
After upgrading BFA to the latest version (1.21.0), the plugin can not add a new failure cause with this error. In addition, it cannot detect failure causes in any jobs. I can still see the list of failure causes,{ noformat quote }A problem occurred while processing the request. Please check [our bug tracker|https://jenkins.io/redirect/issue-tracker] to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. [The users list|https://jenkins.io/redirect/users-mailing-list] might be also useful in understanding what has happened.h2. Stack tracecom.fasterxml.jackson.databind.exc.InvalidTypeIdException: Could not resolve type id 'com.sonyericsson.jenkins.plugins.bfa.model.indication.BuildLogIndication' as a subtype of [simple type, class com.sonyericsson.jenkins.plugins.bfa.model.indication.Indication]: no such class found at [Source: de.undercouch.bson4jackson.io.LittleEndianInputStream@2db3c4b0; pos: 141] (through reference chain: com.sonyericsson.jenkins.plugins.bfa.model.FailureCause["indications"]->java.util.ArrayList[0]) at com.fasterxml.jackson.databind.exc.InvalidTypeIdException.from(InvalidTypeIdException.java:43) at com.fasterxml.jackson.databind.DeserializationContext.invalidTypeIdException(DeserializationContext.java:1635) at com.fasterxml.jackson.databind.DeserializationContext.handleUnknownTypeId(DeserializationContext.java:1187) at com.fasterxml.jackson.databind.jsontype.impl.ClassNameIdResolver._typeFromId(ClassNameIdResolver.java:53) at com.fasterxml.jackson.databind.jsontype.impl.ClassNameIdResolver.typeFromId(ClassNameIdResolver.java:44) at com.fasterxml.jackson.databind.jsontype.impl.TypeDeserializerBase._findDeserializer(TypeDeserializerBase.java:156) at com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer._deserializeTypedForId(AsPropertyTypeDeserializer.java:113) at com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromObject(AsPropertyTypeDeserializer.java:97) at com.fasterxml.jackson.databind.deser.AbstractDeserializer.deserializeWithType(AbstractDeserializer.java:254) at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:288) at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:245) at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:27) at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:530) at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeWithErrorWrapp
[JIRA] (JENKINS-55110) BFA 1.21.0 fails to create a failure cause / scan jobs
Title: Message Title
Bertrand Roussel updated an issue
Jenkins / JENKINS-55110
BFA 1.21.0 fails to create a failure cause / scan jobs
Change By:
Bertrand Roussel
After upgrading BFA to the latest version (1.21.0), the plugin can not add a new failure cause with this error. In addition, it cannot detect failure causes in any jobs. I can still see the list of failure causes, ``` {noformat} A problem occurred while processing the request. Please check [our bug tracker|https://jenkins.io/redirect/issue-tracker] to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. [The users list|https://jenkins.io/redirect/users-mailing-list] might be also useful in understanding what has happened.h2. Stack tracecom.fasterxml.jackson.databind.exc.InvalidTypeIdException: Could not resolve type id 'com.sonyericsson.jenkins.plugins.bfa.model.indication.BuildLogIndication' as a subtype of [simple type, class com.sonyericsson.jenkins.plugins.bfa.model.indication.Indication]: no such class found at [Source: de.undercouch.bson4jackson.io.LittleEndianInputStream@2db3c4b0; pos: 141] (through reference chain: com.sonyericsson.jenkins.plugins.bfa.model.FailureCause["indications"]->java.util.ArrayList[0]) at com.fasterxml.jackson.databind.exc.InvalidTypeIdException.from(InvalidTypeIdException.java:43) at com.fasterxml.jackson.databind.DeserializationContext.invalidTypeIdException(DeserializationContext.java:1635) at com.fasterxml.jackson.databind.DeserializationContext.handleUnknownTypeId(DeserializationContext.java:1187) at com.fasterxml.jackson.databind.jsontype.impl.ClassNameIdResolver._typeFromId(ClassNameIdResolver.java:53) at com.fasterxml.jackson.databind.jsontype.impl.ClassNameIdResolver.typeFromId(ClassNameIdResolver.java:44) at com.fasterxml.jackson.databind.jsontype.impl.TypeDeserializerBase._findDeserializer(TypeDeserializerBase.java:156) at com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer._deserializeTypedForId(AsPropertyTypeDeserializer.java:113) at com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromObject(AsPropertyTypeDeserializer.java:97) at com.fasterxml.jackson.databind.deser.AbstractDeserializer.deserializeWithType(AbstractDeserializer.java:254) at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:288) at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:245) at com.fasterxml.jackson.databind.deser.std.CollectionDeserializer.deserialize(CollectionDeserializer.java:27) at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:530) at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeWithErrorWrappin
[JIRA] (JENKINS-55125) NPE in splitCauses
Title: Message Title
Bertrand Roussel updated an issue
Jenkins / JENKINS-55125
NPE in splitCauses
Change By:
Bertrand Roussel
Not sure what is happening but we have this issue:{noformat}SEVERE: Could not scan build BuildJob #224java.lang.NullPointerExceptionat com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.splitCauses(BuildFailureScanner.java:360)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.findIndications(BuildFailureScanner.java:279)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.findCauses(BuildFailureScanner.java:236)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.scan(BuildFailureScanner.java:162)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.scanIfNotScanned(BuildFailureScanner.java:138)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.onCompleted(BuildFailureScanner.java:117)at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:211)at hudson.model.Run.execute(Run.java:1855)at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)at hudson.model.ResourceController.execute(ResourceController.java:97)at hudson.model.Executor.run(Executor.java:429){noformat}This appears to be because of null 'causes' that is being dereferenced. Note that the job is a pipeline (groovy) job.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
[JIRA] (JENKINS-55125) NPE in splitCauses
Title: Message Title
Bertrand Roussel updated an issue
Jenkins / JENKINS-55125
NPE in splitCauses
Change By:
Bertrand Roussel
Not sure what is happening but we have this issue:{noformat}SEVERE: Could not scan build BuildJob #224java.lang.NullPointerExceptionat com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.splitCauses(BuildFailureScanner.java:360)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.findIndications(BuildFailureScanner.java:279)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.findCauses(BuildFailureScanner.java:236)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.scan(BuildFailureScanner.java:162)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.scanIfNotScanned(BuildFailureScanner.java:138)at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.onCompleted(BuildFailureScanner.java:117)at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:211)at hudson.model.Run.execute(Run.java:1855)at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)at hudson.model.ResourceController.execute(ResourceController.java:97)at hudson.model.Executor.run(Executor.java:429){noformat} This appears to be because of null 'causes' that is being dereferenced.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
[JIRA] (JENKINS-55125) NPE in splitCauses
Title: Message Title Bertrand Roussel created an issue Jenkins / JENKINS-55125 NPE in splitCauses Issue Type: Bug Assignee: Tomas Westling Components: build-failure-analyzer-plugin Created: 2018-12-11 16:03 Environment: Jenkins 2.150.1 BFA 1.21.0 Priority: Major Reporter: Bertrand Roussel Not sure what is happening but we have this issue: SEVERE: Could not scan build BuildJob #224 java.lang.NullPointerException at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.splitCauses(BuildFailureScanner.java:360) at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.findIndications(BuildFailureScanner.java:279) at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.findCauses(BuildFailureScanner.java:236) at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.scan(BuildFailureScanner.java:162) at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.scanIfNotScanned(BuildFailureScanner.java:138) at com.sonyericsson.jenkins.plugins.bfa.BuildFailureScanner.onCompleted(BuildFailureScanner.java:117) at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:211) at hudson.model.Run.execute(Run.java:1855) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429)
[JIRA] (JENKINS-20808) Escaping of single quotes in commit message fails
Title: Message Title Bertrand Roussel commented on JENKINS-20808 Re: Escaping of single quotes in commit message fails Still a valid issue, for instance with the default format (single quotes around Build Failed ) gerrit review , --message 'Build Failed ' --verified INFO: Notifying BuildCompleted to gerrit: gerrit review 9111,1 --message 'Build Failed ahaha! ' ! /apps/proc : FAILURE' --verified -1 Sep 09, 2016 12:28:02 PM com.sonymobile.tools.gerrit.gerritevents.workers.cmd.AbstractSendCommandJob sendCommand SEVERE: Could not run command gerrit review 9111,1 --message 'Build Failed ahaha! ' ! /apps/proc : FAILURE' --verified -1 java.io.IOException: Error during sending command at com.sonymobile.tools.gerrit.gerritevents.workers.cmd.AbstractSendCommandJob.sendCommand2(AbstractSendCommandJob.java:118) at com.sonymobile.tools.gerrit.gerritevents.workers.cmd.AbstractSendCommandJob.sendCommand(AbstractSendCommandJob.java:79) at com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.GerritNotifier.buildCompleted(GerritNotifier.java:118) at com.sonyericsson.hudson.plugins.gerrit.trigger.gerritnotifier.job.ssh.BuildCompletedCommandJob.run(BuildCompletedCommandJob.java:71) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: com.sonymobile.tools.gerrit.gerritevents.ssh.SshException: fatal: "!" is not a valid patch set (1) at com.sonymobile.tools.gerrit.gerritevents.ssh.SshConnectionImpl.executeCommand(SshConnectionImpl.java:254) at com.sonymobile.tools.gerrit.gerritevents.workers.cmd.AbstractSendCommandJob.sendCommand2(AbstractSendCommandJob.java:116) ... 8 more So with single quotes, it's not possible to have single quotes in the message, and if it is double quotes, then it is not possible to have double quotes in the message. I would suggest that we escape single quotes by default for BUILD_STATS since the default is to have single quotes. Add Comment
[JIRA] [gerrit-trigger-plugin] (JENKINS-31379) Gerrit trigger doesn't allow loopback for comments
Title: Message Title Bertrand Roussel created an issue Jenkins / JENKINS-31379 Gerrit trigger doesn't allow loopback for comments Issue Type: Bug Assignee: Bertrand Roussel Components: gerrit-trigger-plugin Created: 03/Nov/15 10:28 PM Priority: Minor Reporter: Bertrand Roussel I want to trigger a job (Project-Verified) when a Gerrit change is set as 'Verified' '1'. I have another independent job (Project-Review) that is in charge of the review of that patch. The problem is that when Project-Review mark the patch as Verified+1, the comment is ignored because the user posting the comment is the Gerrit trigger user. It seems to me that this loop could be allowed as an option, in order to allow such pattern where the Gerrit server act a message queue to decouple jobs. Add Comment
[JIRA] [build-flow-plugin] (JENKINS-30942) retry still trying after build has been aborted
Title: Message Title
Bertrand Roussel created an issue
Jenkins / JENKINS-30942
retry still trying after build has been aborted
Issue Type:
Bug
Assignee:
Nicolas De Loof
Components:
build-flow-plugin
Created:
14/Oct/15 9:26 AM
Environment:
Jenkins ver. 1.609.3 build-flow-plugin 0.18
Priority:
Major
Reporter:
Bertrand Roussel
Given a structure like this:
parallel ( // job 1, 2 and 3 will be scheduled in parallel. { retry(3) { build("job1") }
}, { retry(2) { build("job2") }
} )
If I abord manally the main build, current builds for job1 and job2 will abort, but retry will ... retry to builds these jobs even though everything is aborted.
There is a 'worstAllowed' parameter, but given that ABORT is the 'worst' Result, I don't think I can catch it without accepting all other failures.
It feels like upon failure, retry should check the state of the current build before rescheduling a new build.
[JIRA] [core] (JENKINS-13546) buildWithParameters: return a JSON string when client request it through content-type header
Bertrand Roussel edited a comment on JENKINS-13546 buildWithParameters: return a JSON string when client request it through content-type header @Sune: I see what you mean, I've made few experiments and now I have a better idea of what the "queueItem" actually returns. As for the randomness, as soon as the queued item is being processed, it pops out of the queue, so (maybe) if the process as started before the project gets serialized to be served as a JSON Object, then the queue Item is null. It might not be the exact scenario, but in any case the "queueItem" is indeed not reliable, and the queued item object (WaitingItem) returned when scheduling does not offer much support either (enclosed infos, such as timestamp, etc ... are not kept when creating a build object). I might be wrong, but it seems it would be hard to return informations such as "Ok, I scheduled this task, number is 33 and you will find the build at http://my-jenkins/job/MyJob/33/". This is what I wanted at first but it seems it would be difficult due to the process, which appears to be: Request Processing: Let's queue that WaitingItem # This is where the request result is built Job Processing: Let's take that WaitingItem and process it # This is where a "Build" is created Maybe it would be ok to attribute a GUID to the queued item, and keep that GUID in the build item. At some point it could provide an 'Jenkins instance'-wide id for a build item, which seems more reliable than a Job Name + Build Number relation. I will try to provide a proof of concept by the end of the day. 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] [core] (JENKINS-13546) buildWithParameters: return a JSON string when client request it through content-type header
Bertrand Roussel commented on JENKINS-13546 buildWithParameters: return a JSON string when client request it through content-type header I see what you mean, I've made few experiments and now I have a better idea of what the "queueItem" actually returns. I might be wrong, but it seems it would be hard to return informations such as "Ok, I scheduled this task, number is 33 and you will find the build at http://my-jenkins/job/MyJob/33/". This is what I wanted at first but it seems it would be difficult due to the process, which appears to be: Request Processing: Let's queue that WaitingItem # This is where the request result is built Job Processing: Let's take that WaitingItem and process it # This is where a "Build" is created Maybe it would be ok to attribute a GUID to the queued item, and keep that GUID in the build item. At some point it could provide an 'Jenkins instance'-wide id for a build item, which seems more reliable than a Job Name + Build Number relation. I will try to provide a proof of concept by the end of the day. 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] [core] (JENKINS-13546) buildWithParameters: return a JSON string when client request it through content-type header
Bertrand Roussel commented on JENKINS-13546 buildWithParameters: return a JSON string when client request it through content-type header @Sune: It seems the "queueItem" should contain informations about the scheduled item, could you please provide more details about when this is null ? Is that random (for a same type of build, even if the build has been scheduled, sometimes the queueItem is null, sometimes it isn't), or is that more for some type of builds, etc ... 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-13546) buildWithParameters: return a JSON string when client request it through content-type header
Bertrand Roussel started work on JENKINS-13546 buildWithParameters: return a JSON string when client request it through content-type header Change By: Bertrand Roussel (29/Mar/13 5:00 PM) Status: Reopened In Progress 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-13546) buildWithParameters: return a JSON string when client request it through content-type header
Bertrand Roussel assigned JENKINS-13546 to Bertrand Roussel buildWithParameters: return a JSON string when client request it through content-type header Change By: Bertrand Roussel (29/Mar/13 5:00 PM) Assignee: Bertrand Roussel 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.
