[JIRA] (JENKINS-60654) Add option to ignore bundled plugins

2020-01-06 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador assigned an issue to leemeador  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60654  
 
 
  Add option to ignore bundled plugins   
 

  
 
 
 
 

 
Change By: 
 leemeador  
 
 
Assignee: 
 Natasha Stopa leemeador  
 

  
 
 
 
 

 
 
 

 
 
 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.203896.1578335562000.2939.1578335700325%40Atlassian.JIRA.


[JIRA] (JENKINS-60654) Add option to ignore bundled plugins

2020-01-06 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60654  
 
 
  Add option to ignore bundled plugins   
 

  
 
 
 
 

 
Change By: 
 leemeador  
 
 
URL: 
 https://groups.google.com/forum/#!msg/jenkinsci-dev/8VnvgOVeVIs/9HG0JpfDDAAJ  
 

  
 
 
 
 

 
 
 

 
 
 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.203896.1578335562000.2937.1578335700290%40Atlassian.JIRA.


[JIRA] (JENKINS-60653) Don't treat requested and dependency plugins the same for download

2020-01-06 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador assigned an issue to leemeador  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60653  
 
 
  Don't treat requested and dependency plugins the same for download   
 

  
 
 
 
 

 
Change By: 
 leemeador  
 
 
Assignee: 
 Natasha Stopa leemeador  
 

  
 
 
 
 

 
 
 

 
 
 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.203895.1578334517000.2941.1578335700388%40Atlassian.JIRA.


[JIRA] (JENKINS-60654) Add option to ignore bundled plugins

2020-01-06 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60654  
 
 
  Add option to ignore bundled plugins   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Natasha Stopa  
 
 
Components: 
 plugin-installation-manager-tool  
 
 
Created: 
 2020-01-06 18:32  
 
 
Labels: 
 plugin-manager  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 leemeador  
 

  
 
 
 
 

 
 The use of bundled plugins in today's Jenkins is not well documented. In trying to find information about their usage, via the developers' email list, it was suggested my best bet might be to ignore bundled plugins alltogether. The question I have is whether Jenkins today installs all bundled plugins at startup time. And that could be at initial startup (the very first time after an install) or at every time the war starts running. The impact relates to when the plugin installation manager cli tool (or the install plugins shell script) run. The next paragraph is next to impossible to understand because its so circular. If update manger cli (or script) runs after bundled plugins have been installed automatically, it will take into account the plugins that are installed and the bundled ones are irrelevant. Then plugins might get put back when bundled ones get installed on the next startup. If iupdate manager cli (or script) runs before bundled plugins are installed, and they really are being installed, then the plugins installed by the update manager (or script) will get replaced when the bundled ones get installed. Proposal It's not clear to me that there is any solution to choosing versions for this circular sort of situation. So what I propose is to allow the user to have the plugin manager cli consider bundled plugins by default or, optionally by command line option, ignore bundled plugins completely. Ignoring means not collecting the list of bundled plugins. They will not be 

[JIRA] (JENKINS-60653) Don't treat requested and dependency plugins the same for download

2020-01-06 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60653  
 
 
  Don't treat requested and dependency plugins the same for download   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Natasha Stopa  
 
 
Components: 
 plugin-installation-manager-tool  
 
 
Created: 
 2020-01-06 18:15  
 
 
Labels: 
 plugin-manager  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 leemeador  
 

  
 
 
 
 

 
 The install plugins shell script will ALWAYS download a plugin that is requested. It will only download a dependency plugin, one needed by a requested plugin recursively, if that plugin is not already installed in a version equal or greater than the one required. The current plugin installation manager cli tool treats requested and dependency plugins identically in this regard. Neither requested nor dependency plugins are downloaded if the plugin is already installed and the required version is less than the installed version for that plugin. Change to download a requested plugin even if it is already installed and use the version calculated already using requested and dependency versions. Note that the script will download a plugin more than once since it does version comparisons (for dependency plugins) as it finds the dependencies. The cli tool adds the plugin to the "download list" as it find the dependencies and downloads only once for each plugin. I don't think we should change the cli tool to download multiple times for a single plugin but here are the cases in which the install plugins script it will do that. I may not have thought of all the possible cases: 1) If a plugin is requested more than once, it will be downloaded multiple times. Only the last version downloaded (last version in the requested plugin list) will remain. Note that requesting plugins in txt files, yaml files and via command line option does not make it clear what order 

[JIRA] (JENKINS-60214) Plugin installation manager does not work with other update sites

2020-01-02 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador commented on  JENKINS-60214  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Plugin installation manager does not work with other update sites   
 

  
 
 
 
 

 
 I found some bugs in the 1st PR after it was merged: 1) If you use the command line option to supply an experimental update center, it generates an incorrect URL from which to load the update-center.json. (There is an improper "update-center.actual.json" embedded it it.) 2) If you supply an update center that has a long URL, such as the version specific update centers at cloudbees, it does not generate the correct URL for loading plugin files. The old algorithm was just removing the last part of the URL and finding plugins below that path.  
 

  
 
 
 
 

 
 
 

 
 
 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.203187.1574190061000.1889.1577998440196%40Atlassian.JIRA.


[JIRA] (JENKINS-60214) Plugin installation manager does not work with other update sites

2019-11-21 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60214  
 
 
  Plugin installation manager does not work with other update sites   
 

  
 
 
 
 

 
Change By: 
 leemeador  
 

  
 
 
 
 

 
 I've found that jenkins-plugin-manager-1.0.1 fails when  not  used against  updates.jenkins.io. For example,  the Cloudbees update center  fails  because that site has no update-center.actual.json file available there. There  seems to be  is an update-center.json  for all of the update centers .The actual file has pure json content while the non-actual file has a wrapper around the json  which is  "updateCenter.post( ... json goes here ... );" Someone said that has to do with allowing the file to be more easily compatible with browsers use of _javascript_.  I don't know if the best thing is to get Cloudbees to add the non-actual file or change the code to remove the wrapper text in in the non-actual file and use it.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to 

[JIRA] (JENKINS-60214) Plugin installation manager does not work with other update sites

2019-11-21 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60214  
 
 
  Plugin installation manager does not work with other update sites   
 

  
 
 
 
 

 
Change By: 
 leemeador  
 
 
Summary: 
 Plugin installation manager does not work with  Cloudbees  other  update  site  sites  
 

  
 
 
 
 

 
 
 

 
 
 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.203187.1574190061000.5363.1574368500073%40Atlassian.JIRA.


[JIRA] (JENKINS-60214) Plugin installation manager does not work with Cloudbees update site

2019-11-19 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60214  
 
 
  Plugin installation manager does not work with Cloudbees update site   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 leemeador  
 
 
Components: 
 plugin-installation-manager-tool  
 
 
Created: 
 2019-11-19 19:01  
 
 
Labels: 
 plugin-manager  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 leemeador  
 

  
 
 
 
 

 
 I've found that jenkins-plugin-manager-1.0.1 fails when used against the Cloudbees update center because that site has no update-center.actual.json file available there. There is an update-center.json. The actual file has pure json content while the non-actual file has a wrapper around the json "updateCenter.post( ... json goes here ... );" Someone said that has to do with allowing the file to be more easily compatible with browsers use of _javascript_. I don't know if the best thing is to get Cloudbees to add the non-actual file or change the code to remove the wrapper text in in the non-actual file and use it.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 
 

[JIRA] (JENKINS-60202) Error when --Jenkins-update-manager value has trailing slash

2019-11-18 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-60202  
 
 
  Error when --Jenkins-update-manager value has trailing slash   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Natasha Stopa  
 
 
Components: 
 plugin-installation-manager-tool  
 
 
Created: 
 2019-11-18 17:36  
 
 
Labels: 
 plugin-manager  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 leemeador  
 

  
 
 
 
 

 
 Command line like this:     java -jar jenkins-plugin-manager-1.0.1.jar -f plugins.txt --verbose --plugin-download-directory ~/plugins --no-download --list --war /usr/lib/jenkins/jenkins.war --jenkins-update-center https://jenkins-updates.cloudbees.com/ fails with stack trace containing     java.io.FileNotFoundException: https://jenkins-updates.cloudbees.com//update-center.json Remove the trailing slash from the desired update center and it accepts the supplied update center. (This is the workaround)  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  

[JIRA] (JENKINS-56183) Attempt to (de-)serialize anonymous class: jenkins-core-2.150.3.jar

2019-10-31 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador commented on  JENKINS-56183  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Attempt to (de-)serialize anonymous class: jenkins-core-2.150.3.jar   
 

  
 
 
 
 

 
 We are on 2.164 and getting a similar message in the build agent log /computer//log   Agent successfully connected and online Oct 31, 2019 9:57:07 AM [ssh] Connection established in 2.247 seconds. Oct 31, 2019 10:08:07 AM org.jenkinsci.remoting.util.AnonymousClassWarnings warn WARNING: Attempt to (de-)serialize anonymous class hudson.FilePath$2; see: https://jenkins.io/redirect/serialization-of-anonymous-classes/ Oct 31, 2019 10:13:39 AM org.jenkinsci.remoting.util.AnonymousClassWarnings warn WARNING: Attempt to (de-)serialize anonymous class org.jenkinsci.plugins.gitclient.Git$1; see: https://jenkins.io/redirect/serialization-of-anonymous-classes/ Oct 31, 2019 10:13:40 AM org.jenkinsci.remoting.util.AnonymousClassWarnings warn WARNING: Attempt to (de-)serialize anonymous class org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1; see: https://jenkins.io/redirect/serialization-of-anonymous-classes/ Oct 31, 2019 10:14:57 AM org.jenkinsci.remoting.util.AnonymousClassWarnings warn WARNING: Attempt to (de-)serialize anonymous class org.jenkinsci.plugins.durabletask.FileMonitoringTask$FileMonitoringController$1; see: https://jenkins.io/redirect/serialization-of-anonymous-classes/  
 

  
 
 
 
 

 
 
 

 
 
 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 

[JIRA] (JENKINS-58564) Blue Ocean visualization should indicate parallel stages killed with fastFail

2019-07-18 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58564  
 
 
  Blue Ocean visualization should indicate parallel stages killed with fastFail   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 blueocean-plugin  
 
 
Created: 
 2019-07-18 22:12  
 
 
Environment: 
 2.164  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 leemeador  
 

  
 
 
 
 

 
 When you have a parallel section, and one of the parallel stages fails, and you have fail fast set, All the other parallel stages (that haven't completed) show a message "sending interrupt ..." in the log when they are killed. It would be nice if the visualization let it be easy to see which of the parallel stages died on their own and which were killed because a different on died. Let's say the little circle turns grey. Then you could easily see which one has the log you need to look at to see why it failed. I suspect there is some complexity if two stages fail around the same time and then tell each other to die. Maybe this case can't easily be handled. Even if not, it is my opinion that solving the case where only one failed on its own would be useful. Maybe its as simple as putting that grey circle up if the log for that parallel stage has a message about "sending interrupt..." though I doubt that's the real indicator. (If there were two to fail at the same time there would be too many grey circles.)  
 

  
 
 
 
 

 
 
   

[JIRA] (JENKINS-56457) Regression in timestamper 1.9: Start of maven plugins is logged with different format

2019-06-14 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador commented on  JENKINS-56457  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Regression in timestamper 1.9: Start of maven plugins is logged with different format   
 

  
 
 
 
 

 
 Seeing a similar issue. CB Jenkins 2.164, Timestamp plugin 1.9. If I go to build job and append /timestamps/?appendlog=HH:mm:ss.s it does not show elapsed time and uses the long format UTC time. It looks like this: [Pipeline] sh [2019-06-14T05:36:15.738Z] + env [2019-06-14T05:36:15.738Z] + sort [2019-06-14T05:36:15.738Z] BUILD_DISPLAY_NAME=#740 [2019-06-14T05:36:15.738Z] BUILD_ID=740 [2019-06-14T05:36:15.738Z] BUILD_NUMBER=740 Similar format appears in api calls: 

 

String query = 'elapsed=HH:mm:ss.S=-50'
BufferedReader reader = hudson.plugins.timestamper.api.TimestamperAPI.get().read(build, query)
reader.withCloseable {
while ((line = reader.readLine()) != null) {
logLines.add(line)
println "LOG line read: " + line
}
}
 

 Output is 

 
[Pipeline] echo
11:13:48  LOG line read:   [2019-06-14T04:01:28.865Z] Removing Streams/Foundation/SequenceConsumer@tmp/
[Pipeline] echo
11:13:48  LOG line read:   [2019-06-14T04:01:28.865Z] Removing Streams/Foundation/SequenceConsumerHandler/build/
[Pipeline] echo
11:13:48  LOG line read:   [2019-06-14T04:01:28.865Z] Removing Streams/Foundation/SequenceConsumerHandler/com.aa.lookahead.crew.sequence.parser/SequenceMarshaller/
 

  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You 

[JIRA] (JENKINS-57964) Documentation unclear for node() in scripted pipeline

2019-06-11 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-57964  
 
 
  Documentation unclear for node() in scripted pipeline
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 pipeline  
 
 
Created: 
 2019-06-11 15:23  
 
 
Environment: 
 n/a  
 
 
Labels: 
 documentation scripted node  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 leemeador  
 

  
 
 
 
 

 
 On this page in the documentation, it describes node(). https://jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#node-allocate-node   Some examples of using the operators have no quotes. Some have quotes around the individual components (eg. 'linux' || 'osx'). None have the full correct syntax (eg. 'linux || osx').   If you use the form with the quotes around the individual components, you get an error saying that node() does not allow a boolean argument. Of course, we are used to the error messaages occasionally having no useful information.   I suggest changing the documentation to NOT include the example with quotes around the components. (It says exactly this: For example, "osx (10.11)" || "Windows Server")   I also suggest putting something up at the top that shows a full example with an _expression_ as well as a single agent's label.  
 

  
 
 
 
 

 
 

[JIRA] (JENKINS-57376) Add option so the job run will NOT update GitHub PR status

2019-05-08 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-57376  
 
 
  Add option so the job run will NOT update GitHub PR status   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Kirill Merkushev  
 
 
Components: 
 github-plugin  
 
 
Created: 
 2019-05-08 17:17  
 
 
Environment: 
 2.164  
 
 
Labels: 
 git  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 leemeador  
 

  
 
 
 
 

 
 When I have a build job and a deploy job tied to the same Enterprise GitHub repo, commits run the build job via webhook and the deploy job is run by user clicking 'build' or run from some other job. The status goes back to GitHub when either job completes. Let's say I have a pull request on the repo. The build job (multibranch pipeline) runs and sends status successful which I've configured GitHub to enable merging the pull request due to successful build. Then, someone runs a deploy job (plain pipeline) and the deployment fails due to connectivity. (I'm making this up how I want.) That sends the status back to GitHub and the pull request can no longer be merged. The branches involved matter here. When the deploy job is tied to the same branch as the pull request, the problem definitely occurs. Other branch combination may or may not be a problem. It's been enough of a problem that I've just turned off the GitHub option that only allows a merge of the PR if the Jenkins builds succeed. This enhancement request is asking for an option either via pipeline code or a checkbox on the configure job page that indicates whether the job will return status to GitHub, or not. In pipeline code, it could either be code that disables the status being sent for this one job run OR it 

[JIRA] (JENKINS-34973) RejectedAccessException thrown but no pending script approval added

2019-04-23 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador commented on  JENKINS-34973  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: RejectedAccessException thrown but no pending script approval added   
 

  
 
 
 
 

 
 Same thing happens when the rejected code is in the initialization code to give a @Field its value.  I suspect it becomes a static variable and the exception gets swallowed because its in the initialization for the class or called from inside, so to speak, the constructor. I used a line like this at the top of the script 

@Field List list = [''] * 21
  
 

  
 
 
 
 

 
 
 

 
 
 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-44930) Allow sh to return exit status, stdout and stderr all at once

2018-09-24 Thread leemea...@java.net (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 leemeador commented on  JENKINS-44930  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Allow sh to return exit status, stdout and stderr all at once   
 

  
 
 
 
 

 
 One solution is to have sh() return the output in the case of returnStdout: true as usual and, in the case of failure, throw an exception that could be a subclass of the current failure exception from which you could extract the error return code if you catch it and the console output is present in the exception as well (so you could extract it too).    
 

  
 
 
 
 

 
 
 

 
 
 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.