[JIRA] (JENKINS-47051) Per step "View as plain text" not working

2020-05-04 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-47051  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Per step "View as plain text" not working   
 

  
 
 
 
 

 
 Whoever comes to this ticket searching for a plain text output of a pipeline step, I see a work-around in using BlueOceans REST API, https://SERVER/blue/rest/organizations/jenkins/pipelines/FOLDER1/pipelines/FOLDER2/pipelines/FOLDER3/pipelines/FOLDER4/pipelines/JOB_BASE_NAME/runs/BUILD_ID/nodes/NODE_ID/steps/STEP_ID/log/ The API call shows after clicking the "BlueOcean" link and finding the job. The NODE_ID parameter does not show in the original Jenkins Pipeline Steps rich-format console log, https://SERVER/job/FOLDER1/job/FOLDER2/job/FOLDER3/job/FOLDER4/job/JOB_BASE_NAME/BUILD_ID/execution/node/STEP_ID/log/  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service

2020-03-25 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-20356  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service   
 

  
 
 
 
 

 
 The proof was found in Event Viewer / Windows Logs / Application in a message from Source "Cb Protection Agent Notifier".{noformat}Notification displayed for target "d:\jenkins\workspace\DIR\PROJ@tmp\jenkins-gitclient-ssh196668178943043519.bat" and process "c:\program files\git\mingw64\bin\git.exe".Cb Protection blocked an attempt by git.exe to run jenkins-gitclient-ssh196668178943043519.bat because the file is not approved.  If you require access to this file, please contact your system administrator or submit an approval request.Note that approval requests are processed based on priority and arrival time. Please be patient while your request is reviewed and processed.  Scroll down for diagnostic data.Source[c:\program files\git\mingw64\bin\git.exe] ProcessHash[017b2f5aa11781cd293e1c412472ed3d92d08affd945fa63bb3a633b1a98785c] ProcessPublisher[Johannes Schindelin (Valid[Yes] Trusted[Yes])]Cmd[git.exe fetch --tags --force --progress -- ssh://g...@company.tld:PORT/GROUP/PROJ.git +refs/heads/*:refs/re]ProcessFlags[WrittenFiles:HaveABInfo]KernelProcessFlags[LocalSystem:64Bit:DepEnabled:LocalAdmin]Tags[\device\harddiskvolume1\program files\git\mingw64\bin\git.exe]Target[d:\jenkins\workspace\DIR\PROJ@tmp\jenkins-gitclient-ssh196668178943043519.bat]Notifier[Block] TargetHash[3b29d2bc77bcadb27fc146d767f23d9c46fb5ab7836daa4d0e60134f1e34996b] TargetPublisher[No Publisher (Valid[No] Trusted[Ineligible:No Cert])]Media[Fixed] Device[Unapproved:0x] DeviceFlags[0x]State[Unapproved] Flags[0x0802]Object[File]Rule[File and Path Execute: Unapproved Executables] List[17] Group[100] Id[27]Server[CBPServer.COMPANY.COM:41002]Policy[ MFC COMPANY  High Enforcement] Id[41] Version[0x] CLVersion[211507]Enforcement[20:20:20]User[NT AUTHORITY\SYSTEM] Pid[12616] Tid[12936]Computer[XX] Domain[]Agent[8.1.6.212]OS[Microsoft Windows Server 2008 R2 x64 Server Enterprise Service Pack 1 (6.1.7601)]DateTime[3/24/2020 10:03:49 PM]{noformat}As a work-around I could replace the default option of using the "git" command with using "JGit" in Global Tool configuration, but because CarbonBlack disabled any other invokation of external commands, I resorted to asking the admins to correct the CarbonBlack limit.  I think they added a permission one level above the particular random path to the auto-generated batch files, but I don't know their exact solution.  It worked.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 

[JIRA] (JENKINS-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service

2020-03-25 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-20356  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service   
 

  
 
 
 
 

 
 The proof was found in Event Viewer / Windows Logs / Application in a message from Source "Cb Protection Agent Notifier". 

 
Notification displayed for target "d:\jenkins\workspace\DIR\PROJ@tmp\jenkins-gitclient-ssh196668178943043519.bat" and process "c:\program files\git\mingw64\bin\git.exe".

Cb Protection blocked an attempt by git.exe to run jenkins-gitclient-ssh196668178943043519.bat because the file is not approved.  If you require access to this file, please contact your system administrator or submit an approval request.
Note that approval requests are processed based on priority and arrival time. Please be patient while your request is reviewed and processed.  Scroll down for diagnostic data.

Source[c:\program files\git\mingw64\bin\git.exe] ProcessHash[017b2f5aa11781cd293e1c412472ed3d92d08affd945fa63bb3a633b1a98785c] ProcessPublisher[Johannes Schindelin (Valid[Yes] Trusted[Yes])]
Cmd[git.exe fetch --tags --force --progress -- ssh://g...@company.tld:PORT/GROUP/PROJ.git +refs/heads/*:refs/re]
ProcessFlags[WrittenFiles:HaveABInfo]
KernelProcessFlags[LocalSystem:64Bit:DepEnabled:LocalAdmin]
Tags[\device\harddiskvolume1\program files\git\mingw64\bin\git.exe]
Target[d:\jenkins\workspace\DIR\PROJ@tmp\jenkins-gitclient-ssh196668178943043519.bat]
Notifier[Block] TargetHash[3b29d2bc77bcadb27fc146d767f23d9c46fb5ab7836daa4d0e60134f1e34996b] TargetPublisher[No Publisher (Valid[No] Trusted[Ineligible:No Cert])]
Media[Fixed] Device[Unapproved:0x] DeviceFlags[0x]
State[Unapproved] Flags[0x0802]
Object[File]
Rule[File and Path Execute: Unapproved Executables] List[17] Group[100] Id[27]
Server[CBPServer.COMPANY.COM:41002]
Policy[MFC High Enforcement] Id[41] Version[0x] CLVersion[211507]
Enforcement[20:20:20]
User[NT AUTHORITY\SYSTEM] Pid[12616] Tid[12936]
Computer[XX] Domain[]
Agent[8.1.6.212]
OS[Microsoft Windows Server 2008 R2 x64 Server Enterprise Service Pack 1 (6.1.7601)]
DateTime[3/24/2020 10:03:49 PM]
 

 As a work-around I could replace the default option of using the "git" command with using "JGit" in Global Tool configuration, but because CarbonBlack disabled any other invokation of external commands, I resorted to asking the admins to correct the CarbonBlack limit. I think they added a permission one level above the particular random path to the auto-generated batch files, but I don't know their exact solution. It worked.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
   

[JIRA] (JENKINS-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service

2020-03-24 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-20356  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Git CLI cannot clone on Windows using GIT_SSH to set credentials when running as a service   
 

  
 
 
 
 

 
 For those stumbling on this ticket searching for a similar error saying "permission denied", this may result from (domain) administrators installing Bit9 Parity CarbonBlack to white-list the commands allowed on the machine.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-20 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 The environment clause appears to be ignored by plugins executing code such as the following,{code:groovy}EnvVars vars = build.getEnvironment(listener); {code}My current work-around is to define hard-coded default values for the pipeline "parameters", even for the agent "master" which runs on the same machine with the server.   However, this breaks   (If  Jenkins server 's  needs to run its  own checkout of , say, a pipeline library, then it will fail to use Git on  the  project  server  using  Git from  the agent-targeting  PATH ) .{code:groovy}agent {label 'master'}parameters {string(name: 'FORTIFY_HOME', defaultValue: "/MYTOOLDIR/fortify", description: 'A work-around to the plugin using FORTIFY_HOME of the Jenkins server instead of that of the agent')string(name: 'PATH', defaultValue: "/MYTOOLDIR/fortify/bin:/usr/local/FOO/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", description: 'A work-around to the plugin using PATH of the Jenkins server instead of that of the agent')}{code}I wish Jenkins in general its plugins in particular gave precendence to the agent's environment. I did not try to find the exact API to fetch that in the context of the plugin running on the server but aiming the given "agent".  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups 

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-20 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 The environment clause appears to be ignored by plugins executing code such as the following,{code:groovy}EnvVars vars = build.getEnvironment(listener); {code}My current work-around is to define hard-coded default values for the pipeline "parameters", even for the agent "master" which runs on the same machine with the server.   However, this breaks Jenkins server's own checkout of the project using Git from PATH . .   {code:groovy}agent {label 'master'}parameters {string(name: 'FORTIFY_HOME', defaultValue: "/MYTOOLDIR/fortify", description: 'A work-around to the plugin using FORTIFY_HOME of the Jenkins server instead of that of the agent')string(name: 'PATH', defaultValue: "/MYTOOLDIR/fortify/bin:/usr/local/FOO/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", description: 'A work-around to the plugin using PATH of the Jenkins server instead of that of the agent')}{code}I wish Jenkins in general its plugins in particular gave precendence to the agent's environment. I did not try to find the exact API to fetch that in the context of the plugin running on the server but aiming the given "agent".  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
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-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-20 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 The environment clause appears to be ignored by plugins executing code such as the following, 

 

EnvVars vars = build.getEnvironment(listener); 
 

 My current work-around is to define hard-coded default values for the pipeline "parameters", even for the agent "master" which runs on the same machine with the server... 

 

agent {
label 'master'
}

parameters {
string(name: 'FORTIFY_HOME', defaultValue: "/MYTOOLDIR/fortify", 
description: 'A work-around to the plugin using FORTIFY_HOME of the Jenkins server instead of that of the agent')
string(name: 'PATH', defaultValue: 
"/MYTOOLDIR/fortify/bin:/usr/local/FOO/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", 
description: 'A work-around to the plugin using PATH of the Jenkins server instead of that of the agent')
}
 

 I wish Jenkins in general its plugins in particular gave precendence to the agent's environment. I did not try to find the exact API to fetch that in the context of the plugin running on the server but aiming the given "agent".  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
 

[JIRA] (JENKINS-55864) Getting java.lang.NullPointerException while cloning from Old View to New View

2020-03-18 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov reopened an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55864  
 
 
  Getting java.lang.NullPointerException while cloning from Old View to New View   
 

  
 
 
 
 

 
Change By: 
 Ilguiz Latypov  
 
 
Resolution: 
 Not A Defect  
 
 
Status: 
 Resolved Reopened  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-55864) Getting java.lang.NullPointerException while cloning from Old View to New View

2020-03-18 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-55864  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Getting java.lang.NullPointerException while cloning from Old View to New View   
 

  
 
 
 
 

 
 Same here.   Note the "Caused by" piece that showed in the original stack trace but appears munged by formatting.   {noformat} Caused by: java.lang.NullPointerExceptionCaused: javax.servlet.ServletException at org.kohsuke.stapler.Facet.handleIndexRequest(Facet.java:285){noformat}{noformat}  Recent ChangesSkip to content[Jenkins]Jenkins log in Jenkins Jenkins project Bug tracker Mailing Lists Twitter: @jenkinsci Oops!A problem occurred while processing the request. Please check our bug 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 might be also useful in understanding what has happened.Stack traceorg.apache.commons.jelly.JellyTagException: jar:file:/C:/jenkins/plugins/workflow-job/WEB-INF/lib/workflow-job.jar!/org/jenkinsci/plugins/workflow/job/WorkflowJob/main.jelly:39:70:  java.lang.NullPointerException at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:726) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:281) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:95) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at 

[JIRA] (JENKINS-55864) Getting java.lang.NullPointerException while cloning from Old View to New View

2020-03-18 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-55864  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Getting java.lang.NullPointerException while cloning from Old View to New View   
 

  
 
 
 
 

 
 Same here. 

 
	Recent Changes
Skip to content
[Jenkins]Jenkins
 log in
 

Jenkins

 Jenkins project
 Bug tracker
 Mailing Lists
 Twitter: @jenkinsci
 Oops!

A problem occurred while processing the request. Please check our bug 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 might be also useful in understanding what has happened.
Stack trace

org.apache.commons.jelly.JellyTagException: jar:file:/C:/jenkins/plugins/workflow-job/WEB-INF/lib/workflow-job.jar!/org/jenkinsci/plugins/workflow/job/WorkflowJob/main.jelly:39:70:  java.lang.NullPointerException
	at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:726)
	at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:281)
	at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161)
	at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150)
	at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
	at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:95)
	at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:147)
	at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
	at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
	at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105)
	at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99)
	at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91)
	at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99)
	at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
	at 

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-16 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 I figured the original issue appears fixed  in , and I am just confirming this for  Jenkins 2.226 and current plugins.  Sorry I just noticed Andrew Bayer's fix in this ticket.{code:groovy}pipeline {agent {label 'linux'}environment {PATH="/a/new/bin:$PATH"   }   stages {stage ('build') {steps {echo "PATH=$PATH"echo "env.PATH=${env.PATH}"sh "export -p | grep PATH"}}}}{code}{code:none} Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] node Running on Jenkins in /var/jenkins_home/workspace/System/Test_JENKINS-45916 [Pipeline] { [Pipeline] withEnv [Pipeline] { [Pipeline] stage [Pipeline] { (build) [Pipeline] echo PATH=/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [Pipeline] echo env.PATH=/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [Pipeline] sh + export -p + grep PATH declare -x GEM_PATH="file:/var/jenkins_home/plugins/ruby-runtime/WEB-INF/lib/stapler-jruby-1.209.jar!/gem/" declare -x PATH="/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // withEnv [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS{code}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 
 

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-16 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 I figured the original issue appears fixed in Jenkins 2.226 and current plugins.  Sorry I just noticed Andrew Bayer's fix in this ticket.  {code:groovy}pipeline {agent {label 'linux'}environment {PATH="/a/new/bin:$PATH"   }   stages {stage ('build') {steps {echo "PATH=$PATH"echo "env.PATH=${env.PATH}"sh "export -p | grep PATH"}}}}{code}{code: text none } Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] node Running on Jenkins in /var/jenkins_home/workspace/System/Test_JENKINS-45916 [Pipeline] { [Pipeline] withEnv [Pipeline] { [Pipeline] stage [Pipeline] { (build) [Pipeline] echo PATH=/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [Pipeline] echo env.PATH=/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [Pipeline] sh + export -p + grep PATH declare -x GEM_PATH="file:/var/jenkins_home/plugins/ruby-runtime/WEB-INF/lib/stapler-jruby-1.209.jar!/gem/" declare -x PATH="/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // withEnv [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS{code}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

 

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-16 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 I figured the original issue appears fixed in Jenkins 2.226 and current plugins.  Sorry I just noticed Andrew Bayer's fix in this ticket. ``` {code: groovy } pipeline {agent {label 'linux'}environment {PATH="/a/new/bin:$PATH"   }   stages {stage ('build') {steps {echo "PATH=$PATH"echo "env.PATH=${env.PATH}"sh "export -p | grep PATH"}}}} ``` {code}  ``` {code: text }  Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] node Running on Jenkins in /var/jenkins_home/workspace/System/Test_JENKINS-45916 [Pipeline] { [Pipeline] withEnv [Pipeline] { [Pipeline] stage [Pipeline] { (build) [Pipeline] echo PATH=/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [Pipeline] echo env.PATH=/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [Pipeline] sh + export -p + grep PATH declare -x GEM_PATH="file:/var/jenkins_home/plugins/ruby-runtime/WEB-INF/lib/stapler-jruby-1.209.jar!/gem/" declare -x PATH="/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // withEnv [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS ``` {code}  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-16 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 I figured the original issue appears fixed in Jenkins 2.226 and current plugins. Sorry I just noticed Andrew Bayer's fix in this ticket. ```groovy pipeline { agent  { label 'linux' }  environment  { PATH="/a/new/bin:$PATH" }  stages { stage ('build') { steps { echo "PATH=$PATH" echo "env.PATH=${env.PATH}" sh "export -p | grep PATH" } } } } ``` ```text Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] node Running on Jenkins in /var/jenkins_home/workspace/System/Test_JENKINS-45916 [Pipeline] { [Pipeline] withEnv [Pipeline] { [Pipeline] stage [Pipeline]  { (build) [Pipeline] echo PATH=/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [Pipeline] echo env.PATH=/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [Pipeline] sh + export -p + grep PATH declare -x GEM_PATH="file:/var/jenkins_home/plugins/ruby-runtime/WEB-INF/lib/stapler-jruby-1.209.jar!/gem/" declare -x PATH="/a/new/bin:/usr/local/nvm/versions/node/v10.15.0/bin:/usr/local/openjdk-8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" [Pipeline] }  [Pipeline] // stage [Pipeline] } [Pipeline] // withEnv [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESS ```  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
You received this message because you are subscribed to 

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-12 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 Never mind, I see the magic recipe.  I still don't know the exact difference between "declarative" and "scripting", but I am mortal as well 

the PATH+EXTRA system works for Scripted Pipeline. If it does not work for Declarative, please file a separate RFE in pipeline-model-definition-plugin. Workaround would I guess be something like (untested) 

 

environment {
  STUFF = "${MTI_HOME}/linux:${MTI_HOME}/bin:${QUARTUS_HOME}/bin:${DCP_LOC}/bin"
}
// …
steps {
  withEnv(["PATH+EXTRA=$STUFF"]) {
sh 'whatever'
  }
}
 


 https://issues.jenkins-ci.org/browse/JENKINS-41339?focusedCommentId=357645=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-357645    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





-- 
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 

[JIRA] (JENKINS-45916) Path is not getting set correctly in pipeline when there is a variable present

2020-03-12 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-45916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Path is not getting set correctly in pipeline when there is a variable present   
 

  
 
 
 
 

 
 What does that mean for the mere mortals?  Is "steps" or "sh" the thing to avoid?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)  
 
 

 
   
 

  
 

  
 

   





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


[JIRA] (JENKINS-6957) Windows slave fails to find java

2020-01-10 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-6957  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Windows slave fails to find java   
 

  
 
 
 
 

 
 The "system cannot find the file specified" error results from the poor service wrapper architecture that freezes the java.exe location in the "executable" XML tag inside its jenkins-slave.xml.[https://mohitgoyal.co/2016/12/18/failed-to-start-jenkins-after-updating-java/] I also found that it helps to comment out the other tag enabling a live update of the slave JAR.  When this update is enabled, the service fails to start  silently trying .  The wrapper log shows an attempt  to download the file and timing out without giving a verbose reason for this.   
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-6957) Windows slave fails to find java

2020-01-10 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-6957  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Windows slave fails to find java   
 

  
 
 
 
 

 
 The "system cannot find the file specified"  error  results from the poor service wrapper architecture that freezes the java.exe location in the "executable" XML tag inside its jenkins-slave.xml. [ https://mohitgoyal.co/2016/12/18/failed-to-start-jenkins-after-updating-java/ ] I also found that it helps to comment out the other tag enabling a live update of the slave JAR.  When this update is enabled, the service fails to start silently trying to download the file and timing out without giving a verbose reason for this.   
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-6957) Windows slave fails to find java

2020-01-10 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-6957  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Windows slave fails to find java   
 

  
 
 
 
 

 
 The "system cannot find the file specified" results from the poor service wrapper architecture that freezes the java.exe location in the "executable" XML tag inside its jenkins-slave.xml. https://mohitgoyal.co/2016/12/18/failed-to-start-jenkins-after-updating-java/  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-58835) recognize file's encodings

2019-08-06 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-58835  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: recognize file's encodings   
 

  
 
 
 
 

 
 Related to JENKINS-53901.  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-58835) recognize file's encodings

2019-08-06 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58835  
 
 
  recognize file's encodings   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 workflow-basic-steps-plugin  
 
 
Created: 
 2019-08-06 22:38  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Ilguiz Latypov  
 

  
 
 
 
 

 
 It would be nice if the readFile basic step could recognize the file's encoding.  (Writing a file with writeFile can store a BOM at the beginning to help in recognizing the character set later, but this must be only a non-default option to preserve backward compatibility with earlier groovy code reading the created files.  This agrees with a rule of thumb "accept liberally, produce conservatively"). There is no need to reinvent the wheel.  Using (and white-listing) groovy.util.CharsetToolkit can make this easy.   https://github.com/groovy/groovy-core/blob/GROOVY_2_4_X/src/main/groovy/util/CharsetToolkit.java#L388   http://docs.groovy-lang.org/latest/html/api/groovy/util/CharsetToolkit.html#getReader()   https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/workflow-basic-steps-2.18/src/main/java/org/jenkinsci/plugins/workflow/steps/ReadFileStep.java    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-29 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 This appears a post-modern BOM that is supposed to tell the encoding of the file before decoding it.{noformat}  +--+--+  | Leading sequence | Encoding |  +--+--+  | FF FE 00 00  | UTF-32LE |  | 00 00 FE FF  | UTF-32BE |  | FF FE| UTF-16LE |  | FE FF| UTF-16BE |  | EF BB BF | UTF-8|  +--+--+{noformat}[http://www.rfc-editor.org/rfc/rfc4329.txt]So readFile needs a mode (or a special value for  the {{  encoding }} parameter ) to enable automatic decoding of that post-modern BOM and then apply the detected decoding to the rest of the contents.  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-29 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 This appears a post-modern BOM that is supposed to tell the encoding of the file before decoding it.{noformat}  +--+--+  | Leading sequence | Encoding |  +--+--+  | FF FE 00 00  | UTF-32LE |  | 00 00 FE FF  | UTF-32BE |  | FF FE| UTF-16LE |  | FE FF| UTF-16BE |  | EF BB BF | UTF-8|  +--+--+{noformat}[http://www.rfc-editor.org/rfc/rfc4329.txt]So readFile needs a mode (or a special value for the {{encoding}} parameter) to  enable automatic decoding of that  sense the  post-modern BOM and  then apply  decode  the  detected decoding to the  rest of the contents  accordingly .  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-29 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 This appears a post-modern BOM that is supposed to tell the encoding of the file before decoding it. 

 
  +--+--+
  | Leading sequence | Encoding |
  +--+--+
  | FF FE 00 00  | UTF-32LE |
  | 00 00 FE FF  | UTF-32BE |
  | FF FE| UTF-16LE |
  | FE FF| UTF-16BE |
  | EF BB BF | UTF-8|
  +--+--+ 

 http://www.rfc-editor.org/rfc/rfc4329.txt So readFile needs a mode (or a special value for encoding) to enable automatic decoding of that post-modern BOM and then apply the detected decoding to the rest of the contents.  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-26481) Mishandling of binary methods accepting Closure

2019-07-23 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-26481  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Mishandling of binary methods accepting Closure   
 

  
 
 
 
 

 
 Another limit is still annoying because it silently returns from a NonCPS method calling a CPS method. {code:java}@NonCPSpublic static String readCurrentVersion(String fileContent) {def xml = new XmlSlurper().parseText( Strings. deBOM(fileContent))String retval = "${xml.metadata.version}"xml = nullreturn retval}// Omitted @NonCPS herepublic static CharSequence deBOM(CharSequence s) {[...]return s}{code}Calling readCurrentVersion from the above unexpectedly returned the entire fileContent.  This is probably another unexpected behaviour but seems worth mentioning in the documentation.   
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-26481) Mishandling of binary methods accepting Closure

2019-07-23 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-26481  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Mishandling of binary methods accepting Closure   
 

  
 
 
 
 

 
 Another limit is still annoying because it silently returns from a NonCPS method calling a CPS method. {code:java}@NonCPSpublic static String readCurrentVersion(String fileContent) {def xml = new XmlSlurper().parseText(Strings.deBOM(fileContent))String retval = "${xml.metadata.version}"xml = nullreturn retval}// Omitted @NonCPS herepublic static CharSequence deBOM(CharSequence s) {[...]return s}{code}Calling  updateMyXML  readCurrentVersion  from the above unexpectedly returned the entire fileContent.  This is probably another unexpected behaviour but seems worth mentioning in the documentation.   
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-26481) Mishandling of binary methods accepting Closure

2019-07-23 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-26481  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Mishandling of binary methods accepting Closure   
 

  
 
 
 
 

 
 Another limit is still annoying because it silently returns from a NonCPS method calling a CPS method.   

 

@NonCPS
public static String readCurrentVersion(String fileContent) {
def xml = new XmlSlurper().parseText(Strings.deBOM(fileContent))
String retval = "${xml.metadata.version}"
xml = null
return retval
}

// Omitted @NonCPS here
public static CharSequence deBOM(CharSequence s) {
[...]
return s
}
 

 Calling updateMyXML from the above unexpectedly returned the entire fileContent.  This is probably another unexpected behaviour but seems worth mentioning in the documentation.    
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-22 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 I guess Sam used vague wording.  It's the files that harbour the UTF-8-encoded BOM mark at the beginning, which is useless because UTF-8's bytewise storage does not depend on the architecture's byte order.{code:java}$ python -c 'u = b"\xEF\xBB\xBF".decode("utf-8"); print "%04X" % (ord(u[0]),)'FEFF{code}Microsoft creates files with these useless but confusing 3 bytes at the beginning of its UTF-8-encoded files.  Now every program that reads such files needs to trim the Unicode BOM character at the beginning of the contents after decoding to Unicode.{code:java}public static CharSequence deBOM(CharSequence  fromUTF8  s ) {if ( fromUTF8 s  == null) {return null} else if ( fromUTF8 s .length() == 0) {return  fromUTF8  s } else if ( fromUTF8 s [0] == '\uFEFF') {return  fromUTF8[1  s . .- drop( 1 ] ) } else {return  fromUTF8  s }}{code}[https://stackoverflow.com/questions/5406172/utf-8-without-bom]Perhaps, newer XMLSlurper performs this santitation.  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-22 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 I guess Sam used vague wording.  It's the files that harbour the UTF-8-encoded BOM mark at the beginning, which is useless because UTF-8's bytewise storage does not depend on the architecture's byte order.{code:java}$ python -c 'u = b"\xEF\xBB\xBF".decode("utf-8"); print "%04X" % (ord(u[0]),)'FEFF{code}Microsoft creates files with these useless but confusing 3 bytes at the beginning of its UTF-8-encoded files.  Now every program that reads such files needs to trim the Unicode BOM character at the beginning of the contents after decoding to Unicode.{code:java}public static  String  CharSequence  deBOM( String CharSequence  fromUTF8) {if(fromUTF8  == null) {return null}else if(fromUTF8.length() == 0) {return fromUTF8}else if(fromUTF8 [0] == '\uFEFF') {return fromUTF8[1..-1]}else {return fromUTF8}}  {code}[https://stackoverflow.com/questions/5406172/utf-8-without-bom]Perhaps, newer XMLSlurper performs this santitation.  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-22 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 I guess Sam used vague wording.  It's the files that harbour the UTF-8-encoded BOM mark at the beginning, which is useless because UTF-8's bytewise storage does not depend on the architecture's byte order.{code:java}$ python -c 'u = b"\xEF\xBB\xBF".decode("utf-8"); print "%04X" % (ord(u[0]),)'FEFF{code}Microsoft creates files with these useless but confusing 3 bytes at the beginning of its UTF-8-encoded files.  Now every program that reads such files needs to trim the Unicode BOM character at the beginning of the contents after decoding to Unicode.{code:java}public static CharSequence deBOM(CharSequence fromUTF8) {if (fromUTF8 == null) {return null}  else if(fromUTF8.length() == 0) {return fromUTF8}  else if(fromUTF8[0] == '\uFEFF') {return fromUTF8[1..-1]}  else {return fromUTF8}}  {code}[https://stackoverflow.com/questions/5406172/utf-8-without-bom]Perhaps, newer XMLSlurper performs this santitation.  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-22 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 I guess Sam used vague wording.  It's the files that harbour the UTF-8-encoded BOM mark at the beginning, which is useless because UTF-8's bytewise storage does not depend on the architecture's byte order.{code:java}$ python -c 'u = b"\xEF\xBB\xBF".decode("utf-8"); print "%04X" % (ord(u[0]),)'FEFF{code}Microsoft creates files with these useless but confusing 3 bytes at the beginning of its UTF-8-encoded files.  Now every program that reads such files needs to trim the Unicode BOM character at the beginning of the contents after decoding to Unicode.{code:java}public static String deBOM(String fromUTF8) {if(fromUTF8[0] == '\uFEFF') {return fromUTF8[1..-1]}else {return fromUTF8}}{code}[https://stackoverflow.com/questions/5406172/utf-8-without-bom]   Perhaps, newer  SlurpXML  XMLSlurper  performs this santitation.  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-22 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 I guess Sam used vague wording.  It's the files that harbour the UTF-8-encoded BOM mark at the beginning, which is useless because UTF-8's bytewise storage does not depend on the architecture's byte order.{code:java}$ python -c 'u = b"\xEF\xBB\xBF".decode("utf-8"); print "%04X" % (ord(u[0]),)'FEFF{code}Microsoft creates files with these useless but confusing 3 bytes at the beginning of its UTF-8-encoded files.  Now every program that reads such files needs to trim the Unicode BOM character at the beginning of the contents after decoding to Unicode.{code:java}public static String deBOM(String fromUTF8) {if(fromUTF8[0] == '\uFEFF') {return fromUTF8[1..-1]}else {return fromUTF8}}{code}  [ https://stackoverflow.com/questions/5406172/utf-8-without-bom ]   Perhaps, newer SlurpXML performs this santitation.  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-22 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 I guess Sam used vague wording.  It's the files that harbour the UTF-8-encoded BOM mark at the beginning, which is useless because UTF-8's bytewise storage does not depend on the architecture's byte order.{code:java}$ python -c 'u = b"\xEF\xBB\xBF".decode("utf-8"); print "%04X" % (ord(u[0]),)'FEFF{code}Microsoft creates files with these useless but confusing 3 bytes at the beginning of its UTF-8-encoded files.  Now every program that reads such files needs to trim the Unicode BOM character at the beginning of the contents after decoding to Unicode.{code:java}public static String deBOM(String fromUTF8) {if(fromUTF8[0] == '\uFEFF') {return fromUTF8[1..-1]}else {return fromUTF8}}{code} https://stackoverflow.com/questions/5406172/utf-8-without-bom  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-53901) Using readFile does not handle UTF-8 with BOM files

2019-07-22 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-53901  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Using readFile does not handle UTF-8 with BOM files   
 

  
 
 
 
 

 
 I guess Sam used vague wording.  It's the files that harbour the UTF-8-encoded BOM mark at the beginning, which is useless because UTF-8's bytewise storage does not depend on the architecture's byte order. 

 

$ python -c 'u = b"\xEF\xBB\xBF".decode("utf-8"); print "%04X" % (ord(u[0]),)'
FEFF
 

 Microsoft creates files with these useless but confusing 3 bytes at the beginning of its UTF-8-encoded files.  Now every program that reads such files needs to trim the Unicode BOM character at the beginning of the contents after decoding to Unicode. 

 

public static String deBOM(String fromUTF8) {
if(fromUTF8[0] == '\uFEFF') {
return fromUTF8[1..-1]
}
else {
return fromUTF8
}
}
 

  
 

  
 
 
 
 

 
 
 

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


[JIRA] (JENKINS-58256) Improve Jenkins timeout messages for tracing their cause

2019-06-28 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58256  
 
 
  Improve Jenkins timeout messages for tracing their cause   
 

  
 
 
 
 

 
Change By: 
 Ilguiz Latypov  
 
 
Issue Type: 
 Bug Improvement  
 

  
 
 
 
 

 
 
 

 
 
 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.200320.1561742671000.11928.1561743780177%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-58256) Improve Jenkins timeout messages for tracing their cause

2019-06-28 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58256  
 
 
  Improve Jenkins timeout messages for tracing their cause   
 

  
 
 
 
 

 
Change By: 
 Ilguiz Latypov  
 

  
 
 
 
 

 
 I blamed our vendor for misinterpreting a timeout option in their code.  They helpfully pointed out that their code did not generate the error messages "Cancelling nested steps due to timeout" and "Sending interrupt signal to process".Searching for the source of these messages on Github, even after scoping to the jenkinsci organization, was a challenge.  For one, some recent branches did not carry these messages. I thought that being explicit in the log messages would not hurt (I think of a progress we made since the Unix times with their say-not-a-single-word-more idea).   E.g., the messages can mention the "timeout" DSL clause that was the origin of it (with or without its location) and the amount of time that was allocated in that clause.  [https://github.com/jenkinsci/workflow-durable-task-step-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/durable_task/DurableTaskStep.java#L405] [https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/stable/src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java#L177]   
 

  
 
 
 
 

 
 
 

 
 
 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 

[JIRA] (JENKINS-58256) Improve Jenkins timeout messages for tracing their cause

2019-06-28 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58256  
 
 
  Improve Jenkins timeout messages for tracing their cause   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 durable-task-plugin, workflow-basic-steps-plugin  
 
 
Created: 
 2019-06-28 17:24  
 
 
Labels: 
 user-experience pipeline  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Ilguiz Latypov  
 

  
 
 
 
 

 
 I blamed our vendor for misinterpreting a timeout option in their code.  They helpfully pointed out that their code did not generate the error messages "Cancelling nested steps due to timeout" and "Sending interrupt signal to process". Searching for the source of these messages on Github, even after scoping to the jenkinsci organization, was a challenge.  For one, some recent branches did not carry these messages.   I thought that being explicit in the log messages would not hurt (I think of a progress we made since the Unix times with their say-not-a-single-word-more idea).   https://github.com/jenkinsci/workflow-durable-task-step-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/durable_task/DurableTaskStep.java#L405   https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/stable/src/main/java/org/jenkinsci/plugins/workflow/steps/TimeoutStepExecution.java#L177    
 

  
 
 
 
 

 
 
 

 

[JIRA] (JENKINS-58131) Jenkins master propagates environment variables to agents running a pipeline

2019-06-26 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-58131  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Jenkins master propagates environment variables to agents running a pipeline   
 

  
 
 
 
 

 
 Thanks to my colleague I saw the Jenkins machine's configuration UI page (which was not available to me) and noticed the "Tool locations" thing which selected some Java version option probably defined in the Jenkins system configuration.  I am guessing this was the root cause of the bug.  The "tool locations" drop-down in computer configuration should account for major OS differences such as directory notation in JAVA_HOME for Windows and MacOS.   The system configuration should recognize this chance and offer at least two versions of each environment variable to be specified.  Selecting the respective option in the computer configuration will automatically choose one of the two depending on the computer's OS.    
 

  
 
 
 
 

 
 
 

 
 
 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.200176.1561073587000.10116.1561583760101%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-58131) Jenkins master propagates environment variables to agents running a pipeline

2019-06-26 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-58131  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Jenkins master propagates environment variables to agents running a pipeline   
 

  
 
 
 
 

 
 Thanks to my colleague I saw the Jenkins machine's configuration UI page (which was not available to me) and noticed the "Tool locations" thing which selected some Java version option probably defined in the Jenkins system configuration.  I am guessing this was the root cause of the bug.  The "tool locations" drop-down in computer configuration should account for major OS differences such as directory notation in JAVA_HOME for Windows and MacOS.    
 

  
 
 
 
 

 
 
 

 
 
 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.200176.1561073587000.10114.1561583640220%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-58131) Jenkins master propagates environment variables to agents running a pipeline

2019-06-20 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-58131  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Jenkins master propagates environment variables to agents running a pipeline   
 

  
 
 
 
 

 
 Setting agent at the top of the pipeline DSL rather than in its stage produced the same outputs.  
 

  
 
 
 
 

 
 
 

 
 
 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.200176.1561073587000.5005.1561073700118%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-58131) Jenkins master propagates environment variables to agents running a pipeline

2019-06-20 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-58131  
 
 
  Jenkins master propagates environment variables to agents running a pipeline   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 pipeline  
 
 
Created: 
 2019-06-20 23:33  
 
 
Environment: 
 2.138.4  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Ilguiz Latypov  
 

  
 
 
 
 

 
 I defined a Jenkins pipeline job with a Node parameter JENKINS_PARAM_RUN_NODE and the following script, 

 

pipeline {
agent none
stages {
stage('Run') {
agent {
label "${env.JENKINS_PARAM_RUN_NODE}"
}
steps {
script {
echo 'Hello World'
sh 'export -p'
}
}
}
}
}
 

 This showed JAVA_HOME of the Windows master despite selecting a MacOS agent. 

 
...
+ export -p
...
export JAVA_HOME="C:\\Program Files\\Java\\jdk1.8.0_211"
 

 Blanking the env variable exposes the MacOS agent's value, 

 

environment {
JAVA_HOME = ''
  

[JIRA] (JENKINS-54008) Loading library fails - Error fetching remote repo 'origin'

2019-06-12 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-54008  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Loading library fails - Error fetching remote repo 'origin'   
 

  
 
 
 
 

 
 Ah sorry I targeted a wrong bug. I thought it was related to my frustration with the git plugin showing an error implying connectivity issues,{noformat}fatal: Could not read from remote repository{noformat}I think if the git plugin could add this trace message before invoking git,{noformat}echo "Checking out branch ${branch} with credentials ${credentialsId} from ${url} ..."{noformat}dozens of devops would be happier.My problem resolved when I saw that I was using a wrong credential, which did not agree with the error message.  Oh and whoever suggested to try a bare {{git@git../repo.git}} URL on StackOverflow: this ignored the port number after the host name (we use a TCP port  for reasons unknown).  The  "  proper "  {{ssh:// git@ HOST:PORT/REPO.git}} URL worked.  
 

  
 
 
 
 

 
 
 

 
 
 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.194621.1539241642000.25955.1560347460544%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54008) Loading library fails - Error fetching remote repo 'origin'

2019-06-11 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-54008  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Loading library fails - Error fetching remote repo 'origin'   
 

  
 
 
 
 

 
 Ah sorry I targeted a wrong bug.  I thought it was related to my frustration with the git plugin showing an error implying connectivity issues,  {noformat}fatal: Could not read from remote repository{noformat}  I think if the git plugin could add this trace message before invoking git,  {noformat}echo "Checking out branch ${branch} with credentials ${credentialsId} from ${url} ..."{noformat}  dozens of devops would be happier.My problem resolved when I saw that I was using a wrong credential, which did not agree with the error message.   Oh and whoever suggested to try a bare {{git@git../repo.git}} URL on StackOverflow: this ignored the port number after the host name (we use a TCP port  for reasons unknown).  The proper {{ssh://HOST:PORT/REPO.git}} URL worked.  
 

  
 
 
 
 

 
 
 

 
 
 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.194621.1539241642000.25135.1560259441199%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54008) Loading library fails - Error fetching remote repo 'origin'

2019-06-11 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-54008  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Loading library fails - Error fetching remote repo 'origin'   
 

  
 
 
 
 

 
 Ah sorry I targeted a wrong bug.  I thought it was related to my frustration with the git plugin showing  a "  an error implying connectivity issues,{noformat} fatal: Could not read from remote repository " error. {noformat}   I think if the git plugin could add this trace message before invoking git,{noformat}echo "Checking out branch ${branch} with credentials ${credentialsId} from ${url} ..."{noformat}dozens of devops would be happier. Mu My  problem resolved when I saw that I was using a wrong credential, which did not agree with the error message.  
 

  
 
 
 
 

 
 
 

 
 
 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.194621.1539241642000.25121.1560259320171%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54008) Loading library fails - Error fetching remote repo 'origin'

2019-06-11 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-54008  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Loading library fails - Error fetching remote repo 'origin'   
 

  
 
 
 
 

 
 Ah sorry I targeted a wrong bug.  I thought it was related to my frustration with the git plugin showing a "fatal: Could not read from remote repository" error.  I think if the git plugin could add this trace message before invoking git,{noformat}echo "Checking out branch ${branch} with credentials ${credentialsId} from ${url} ..."{noformat}dozens of devops would be happier. Mu problem resolved when I saw that I was using a wrong credential, which did not agree with the error message.  
 

  
 
 
 
 

 
 
 

 
 
 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.194621.1539241642000.25046.1560256620584%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54008) Loading library fails - Error fetching remote repo 'origin'

2019-06-11 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-54008  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Loading library fails - Error fetching remote repo 'origin'   
 

  
 
 
 
 

 
 Ah sorry I targeted a wrong bug. I thought it was related to my frustration with the git plugin showing a "fatal: Could not read from remote repository" error. I think if the git plugin could add this trace message before invoking git, 

 
echo "Checking out branch ${branch} with credentials ${credentialsId} from ${url} ..."
 

 dozens of devops would be happier.  
 

  
 
 
 
 

 
 
 

 
 
 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.194621.1539241642000.25044.1560256620561%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-54008) Loading library fails - Error fetching remote repo 'origin'

2019-06-10 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-54008  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Loading library fails - Error fetching remote repo 'origin'   
 

  
 
 
 
 

 
 I recognize the community spirit of the project and lack of hobby time for its maintainers, but closing an issue just because its submitters did not respond seems evil. The git plugin seems an utmost importance component of Jenkins. Closing issues or suggesting that reporters re-submit part of them as separate bugs always throws me off as if maintainers are not really to own the code.  
 

  
 
 
 
 

 
 
 

 
 
 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.194621.1539241642000.24602.1560183420225%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-45007) git-plugin GitSCM does not support ssh credentials when using checkout in a Jenkinsfile

2019-04-30 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-45007  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: git-plugin GitSCM does not support ssh credentials when using checkout in a Jenkinsfile   
 

  
 
 
 
 

 
 Was the source code analysis in the bug description flawed, then?  
 

  
 
 
 
 

 
 
 

 
 
 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-45041) Shared library pluging - can't use getResource to load a resource?

2018-09-13 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-45041  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Shared library pluging - can't use getResource to load a resource?   
 

  
 
 
 
 

 
 It's a pity libraryResource() is shy about selecting the currently active implicit library's resource.  Instead I get an error, 

 

hudson.AbortException: Library resource com/COMPANY/FILE.EXT ambiguous among libraries [VER1, VER2]
 

 If the pipeline plugin has a way to select the innermost folder's implicit library, it could apply the same algorithm (or stick to the active version) when resolving the library resource.  
 

  
 
 
 
 

 
 
 

 
 
 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-27084) SVN authentication fails using subversion plugin v.2.5

2016-07-15 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov edited a comment on  JENKINS-27084  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: SVN authentication fails using subversion plugin v.2.5   
 

  
 
 
 
 

 
 Setting the svnkit.http.methods property to Basic in both the master and the slave did not make a difference for me. The source code of svnkit authentication looks like a maze of protocols, managers and special cases.  So I followed someone else's work-around by setting the Jenkins project's SCM to None and using the Cygwin's svn command in the first build step to check out the code.  I had to add "--username USER --password PASSWORD" in a one-off invocation of the job to get svn store the credentials in the Jenkins agent's home.{code:none}set svn_opts=--non-interactive --trust-server-cert-failures unknown-ca,cn-mismatch,expiredif exist .svn\nul ( %cygbinslash%svn.exe update %svn_opts%) else (%cygbinslash%svn.exe co %svn_opts% https://SERVER:PORT/svn/REPO/trunk/DIR .){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-27084) SVN authentication fails using subversion plugin v.2.5

2016-07-15 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Ilguiz Latypov commented on  JENKINS-27084  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: SVN authentication fails using subversion plugin v.2.5   
 

  
 
 
 
 

 
 The source code of svnkit authentication looks like a maze of protocols, managers and special cases. So I followed someone else's work-around by setting the Jenkins project's SCM to None and using the Cygwin's svn command in the first build step to check out the code. I had to add "--username USER --password PASSWORD" in a one-off invocation of the job to get svn store the credentials in the Jenkins agent's home. 

 

set svn_opts=--non-interactive --trust-server-cert-failures unknown-ca,cn-mismatch,expired
if exist .svn\nul ( 
%cygbinslash%svn.exe update %svn_opts%
) else (
%cygbinslash%svn.exe co %svn_opts% https://SERVER:PORT/svn/REPO/trunk/DIR .
)
 

  
 

  
 
 
 
 

 
 
 

 
 
 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] [teamconcert-plugin] (JENKINS-20994) Make "Just accept and fetch from a build workspace" more full featured

2016-06-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov commented on  JENKINS-20994 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Make "Just accept and fetch from a build workspace" more full featured  
 
 
 
 
 
 
 
 
 
 
Enabling the "create directories for components" checkbox resolved this in the version 1.2.0 of the plugin. The Jazz work item 296206 shows as resolved on March 1, 2016. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-09 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov commented on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 
I used another work-around avoiding auto-install altogether. For this I added a JDK installation named jdk-per-node in the Jenkins configuration page /configure, left its JAVA_HOME parameter empty and the Install automatically checkbox unchecked. Then I proceeded to the slave node configuration page /computer/FOO/configure, checked Tool Locations checkbox, selected (JDK) jdk-per-node and typed in a directory containing a manually installed JDK on FOO. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [slave-setup-plugin] (JENKINS-16816) slave-agent.jnlp produces wrong url for remoting.jar

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov commented on  JENKINS-16816 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: slave-agent.jnlp produces wrong url for remoting.jar  
 
 
 
 
 
 
 
 
 
 
My issue with starting the agent disappeared but I did not track the history of changes leading to this. I do remember rebooting the server machine (which means this restarted Tomcat 8). 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov edited a comment on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 I saw exit code 1,619 not -80.  Checking the Event Viewer of the slave node showed a path to the installer that did not exist after the failure,{code: }Started by user tomcatBuilding remotely on XXX in workspace d:\jenkins\slave\workspace\WebGoat-LegacyInstalling d:\jenkins\slave\tools\hudson.model.JDK\c_jenkins_jdk\jdk.exe[c_jenkins_jdk] $ d:\jenkins\slave\tools\hudson.model.JDK\c_jenkins_jdk\jdk.exe /s ADDLOCAL="ToolsFeature" REBOOT=ReallySuppress INSTALLDIR=d:\jenkins\slave\tools\hudson.model.JDK\c_jenkins_jdk /L d:\jenkins\slave\tools\hudson.model.JDK\install4927468808054487502logFailed to install JDK. Exit code=1,619ERROR: nullFinished: FAILURE{code}{code: xml}-      1040   4   0   0x80      39478   Application   XXX.YYY      -   C:\Windows\system32\config\systemprofile\AppData\LocalLow\Oracle\Java\jdk1.8.0_60\jdk1.8.0_60.msi   17912   (NULL)   (NULL)   (NULL)   (NULL)    {code} 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov edited a comment on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 I saw exit code 1,619 not -80.   Checking the Event Viewer of the slave node showed a path to the installer that did not exist after the failure,   {code:}Started by user tomcatBuilding remotely on XXX in workspace d:\jenkins\slave\workspace\WebGoat-LegacyInstalling d:\jenkins\slave\tools\hudson.model.JDK\c_jenkins_jdk\jdk.exe[c_jenkins_jdk] $ d:\jenkins\slave\tools\hudson.model.JDK\c_jenkins_jdk\jdk.exe /s ADDLOCAL="ToolsFeature" REBOOT=ReallySuppress INSTALLDIR=d:\jenkins\slave\tools\hudson.model.JDK\c_jenkins_jdk /L d:\jenkins\slave\tools\hudson.model.JDK\install4927468808054487502logFailed to install JDK. Exit code=1,619ERROR: nullFinished: FAILURE{code} Checking the Event Viewer of the slave node showed a path to the installer that did not exist after the failure, {code:xml}-      1040   4   0   0x80      39478   Application   XXX.YYY      -   C:\Windows\system32\config\systemprofile\AppData\LocalLow\Oracle\Java\jdk1.8.0_60\jdk1.8.0_60.msi   17912   (NULL)   (NULL)   (NULL)   (NULL)    {code} 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov commented on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 
I saw exit code 1,619 not -80. Checking the Event Viewer of the slave node showed a path to the installer that did not exist after the failure, 

 

"http://schemas.microsoft.com/win/2004/08/events/event">
- 
  "MsiInstaller" /> 
  "0">1040 
  4 
  0 
  0x80 
  "2015-09-08T22:36:31.0Z" /> 
  39478 
  Application 
  MLISCCLDA0143.americas.manulife.net 
  "S-1-5-18" /> 
  
- 
  C:\Windows\system32\config\systemprofile\AppData\LocalLow\Oracle\Java\jdk1.8.0_60\jdk1.8.0_60.msi 
  17912 
  (NULL) 
  (NULL) 
  (NULL) 
  (NULL) 
   
  
  
 

 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov edited a comment on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 I saw exit code 1,619 not -80.  Checking the Event Viewer of the slave node showed a path to the installer that did not exist after the failure,{code:xml}-      1040   4   0   0x80      39478   Application    MLISCCLDA0143 XXX . americas.manulife.net YYY       -   C:\Windows\system32\config\systemprofile\AppData\LocalLow\Oracle\Java\jdk1.8.0_60\jdk1.8.0_60.msi   17912   (NULL)   (NULL)   (NULL)   (NULL)    {code} 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov commented on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 
The msi file resided in the current user's directory not SYSTEM's. My node's slave runs in a service as SYSTEM. 
$ find /cygdrive/c/Users//AppData/ -iname "j*.msi" -ls 7599824371459631 21144 

rwxrwx
-- 1 Administrators Domain Users 21649339 Aug 26 15:06 /cygdrive/c/Users//AppData/LocalLow/Oracle/Java/jre1.8.0_60/jre1.8.0_60patch.msi 8162774324880945 23244 

rwxrwx
-- 1 Administrators Domain Users 23798144 Aug 26 15:06 /cygdrive/c/Users//AppData/LocalLow/Oracle/Java/jre1.8.0_60_x64/jre1.8.0_60patch64.msi 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov edited a comment on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 The _msi_ file resided in the current user's directory not SYSTEM's.  My node's slave runs in a service as SYSTEM. {code lang:none} $ find /cygdrive/c/Users//AppData/ -iname "j*.msi" -ls7599824371459631 21144 -rwxrwx---   1 Administrators Domain Users 21649339 Aug 26 15:06 /cygdrive/c/Users//AppData/LocalLow/Oracle/Java/jre1.8.0_60/jre1.8.0_60patch.msi8162774324880945 23244 -rwxrwx---   1 Administrators Domain Users 23798144 Aug 26 15:06 /cygdrive/c/Users//AppData/LocalLow/Oracle/Java/jre1.8.0_60_x64/jre1.8.0_60patch64.msi  {code} 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov edited a comment on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 The _msi_ file resided in the current user's directory not SYSTEM's.  My node's slave runs in a service as SYSTEM.{code  lang :none}$ find /cygdrive/c/Users//AppData/ -iname "j*.msi" -ls7599824371459631 21144 -rwxrwx---   1 Administrators Domain Users 21649339 Aug 26 15:06 /cygdrive/c/Users//AppData/LocalLow/Oracle/Java/jre1.8.0_60/jre1.8.0_60patch.msi8162774324880945 23244 -rwxrwx---   1 Administrators Domain Users 23798144 Aug 26 15:06 /cygdrive/c/Users//AppData/LocalLow/Oracle/Java/jre1.8.0_60_x64/jre1.8.0_60patch64.msi{code} 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov edited a comment on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 The A similarly versioned  _msi_ file resided in the current user's directory not SYSTEM's.  My node's slave runs in a service as SYSTEM.{code:none}$ find /cygdrive/c/Users//AppData/ -iname "j*.msi" -ls7599824371459631 21144 -rwxrwx---   1 Administrators Domain Users 21649339 Aug 26 15:06 /cygdrive/c/Users//AppData/LocalLow/Oracle/Java/jre1.8.0_60/jre1.8.0_60patch.msi8162774324880945 23244 -rwxrwx---   1 Administrators Domain Users 23798144 Aug 26 15:06 /cygdrive/c/Users//AppData/LocalLow/Oracle/Java/jre1.8.0_60_x64/jre1.8.0_60patch64.msi{code} 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [core] (JENKINS-23366) jdk8u5 installation fails on windows slaves

2015-09-08 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov commented on  JENKINS-23366 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: jdk8u5 installation fails on windows slaves  
 
 
 
 
 
 
 
 
 
 
Changing the service to run as my domain account appears to have progressed further (repeating the command manually without the /s switch showed that it stopped with exit code -1 due to another unfinished installation). This gives a quick work-around that will require periodic password updates in the service due to our group policy. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [slave-setup-plugin] (JENKINS-16816) slave-agent.jnlp produces wrong url for remoting.jar

2015-09-03 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov commented on  JENKINS-16816 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: slave-agent.jnlp produces wrong url for remoting.jar  
 
 
 
 
 
 
 
 
 
 
Accessing the /jnlpJars/ directory throws this: 

 

java.lang.StringIndexOutOfBoundsException: String index out of range: -1
	at java.lang.String.substring(String.java:1931)
	at jenkins.model.Jenkins.doJnlpJars(Jenkins.java:3214)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298)
	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161)
	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96)
	at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121)
	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
	... 54 more
 

 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [slave-setup-plugin] (JENKINS-16816) slave-agent.jnlp produces wrong url for remoting.jar

2015-09-03 Thread ilaty...@yahoo.ca (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilguiz Latypov edited a comment on  JENKINS-16816 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: slave-agent.jnlp produces wrong url for remoting.jar  
 
 
 
 
 
 
 
 
 
 Accessing the /jnlpJars/ directory throws this:{code:none}java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1931) at jenkins.model.Jenkins.doJnlpJars(Jenkins.java:3214) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) ... 54 more{code} but /jnlpJars/remoting.jar will prompt to download the jar. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 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] [concurrent-build] (JENKINS-13972) Concurrent matrix builds abort

2013-07-08 Thread ilaty...@yahoo.ca (JIRA)














































Ilguiz Latypov
 commented on  JENKINS-13972


Concurrent matrix builds abort















I figured the per-node configuration of my matrix job received a "job disabled" property.  Sub-projects disabled via "Configuration Slicing/Job Disabled Build Slicer (bool)" in /slicing/jobdisabledbool/ will deny requests for new runs without pointing the reason. 


[USER@MASTER ~]$ diff -u /usr/local/jenkins/data/jobs/MATRIXPROJ/configurations/axis-MATRIX/HOSTNAME{X,Y}/config.xml
--- /usr/local/jenkins/data/jobs/MATRIXPROJ/configurations/axis-MATRIX/HOSTNAMEX/config.xml  2013-06-06 21:43:25.823244000 -0400
+++ /usr/local/jenkins/data/jobs/MATRIXPROJ/configurations/axis-MATRIX/HOSTNAMEY/config.xml  2013-06-07 16:22:46.52994 -0400
@@ -7,7 +7,7 @@
   /properties
   scm class="hudson.scm.NullSCM"/
   canRoamtrue/canRoam
-  disabledtrue/disabled
+  disabledfalse/disabled
   blockBuildWhenDownstreamBuildingfalse/blockBuildWhenDownstreamBuilding
   blockBuildWhenUpstreamBuildingfalse/blockBuildWhenUpstreamBuilding
   triggers class="vector"/




























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] [concurrent-build] (JENKINS-13972) Concurrent matrix builds abort

2013-07-08 Thread ilaty...@yahoo.ca (JIRA)












































 
Ilguiz Latypov
 edited a comment on  JENKINS-13972


Concurrent matrix builds abort
















I figured a node configuration of my matrix job received a "job disabled" property.  Sub-projects disabled via "Configuration Slicing/Job Disabled Build Slicer (bool)" in /slicing/jobdisabledbool/ will deny requests for new runs without pointing the reason. 


[USER@MASTER ~]$ diff -u /usr/local/jenkins/data/jobs/MATRIXPROJ/configurations/axis-MATRIX/HOSTNAME{X,Y}/config.xml
--- /usr/local/jenkins/data/jobs/MATRIXPROJ/configurations/axis-MATRIX/HOSTNAMEX/config.xml  2013-06-06 21:43:25.823244000 -0400
+++ /usr/local/jenkins/data/jobs/MATRIXPROJ/configurations/axis-MATRIX/HOSTNAMEY/config.xml  2013-06-07 16:22:46.52994 -0400
@@ -7,7 +7,7 @@
   /properties
   scm class="hudson.scm.NullSCM"/
   canRoamtrue/canRoam
-  disabledtrue/disabled
+  disabledfalse/disabled
   blockBuildWhenDownstreamBuildingfalse/blockBuildWhenDownstreamBuilding
   blockBuildWhenUpstreamBuildingfalse/blockBuildWhenUpstreamBuilding
   triggers class="vector"/




























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] [concurrent-build] (JENKINS-13972) Concurrent matrix builds abort

2013-06-04 Thread ilaty...@yahoo.ca (JIRA)














































Ilguiz Latypov
 commented on  JENKINS-13972


Concurrent matrix builds abort















I see a machine that aborts a job on its second slave.  Both slaves start via SSH, and the machine runs a Centrify SSH server.

Other 2 machines run a regular SSH server and do not exhibit aborts on their second slaves.



























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] [concurrent-build] (JENKINS-13972) Concurrent matrix builds abort

2013-06-04 Thread ilaty...@yahoo.ca (JIRA)












































 
Ilguiz Latypov
 edited a comment on  JENKINS-13972


Concurrent matrix builds abort
















I see a machine that aborts a job on its second slave.  Both slaves start via SSH, and the machine runs a Centrify SSH server.

Other 2 machines run a regular SSH server and do not exhibit aborts on their second slaves.

We have Jenkins 1.492.



























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.