[JIRA] (JENKINS-23477) git plugin sparse checkout path field does not expand variables
Title: Message Title jlpinardon edited a comment on JENKINS-23477 Re: git plugin sparse checkout path field does not expand variables I'd really like to be able to use variable with sparse checkout. It would be a great help in having more generic jobs and so on...Please, can we have some update on this ? I am not at all a java dev, and I don't want to be hurtful, but 6 years to find a fix seems to me a very long time :(... 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.155700.1403067217000.16382.1587635160565%40Atlassian.JIRA.
[JIRA] (JENKINS-23477) git plugin sparse checkout path field does not expand variables
Title: Message Title jlpinardon commented on JENKINS-23477 Re: git plugin sparse checkout path field does not expand variables I'd really like to be able to use variable with sparse checkout. It would be a great help in having more generic jobs and so on... Please, can we have some update on this ? 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.155700.1403067217000.16358.1587634800527%40Atlassian.JIRA.
[JIRA] (JENKINS-60156) sshGet documentation should be more explanatory about arguments behavior
Title: Message Title jlpinardon updated an issue Jenkins / JENKINS-60156 sshGet documentation should be more explanatory about arguments behavior Change By: jlpinardon Component/s: ssh-steps-plugin Component/s: ssh-plugin 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.203022.1573653969000.2382.1574065380541%40Atlassian.JIRA.
[JIRA] (JENKINS-60156) sshGet documentation should be more explanatory about arguments behavior
Title: Message Title jlpinardon updated an issue Jenkins / JENKINS-60156 sshGet documentation should be more explanatory about arguments behavior Change By: jlpinardon Neither the [ssh step plugin documentation|https://jenkins.io/doc/pipeline/steps/ssh-steps/#sshget-ssh-steps-sshget-get-a-filedirectory-from-remote-node] nor the [SSH Step README|https://github.com/jenkinsci/ssh-steps-plugin] file (_referenced as more detailed in the former doc !!) github project explains clearly the behavior controled by each arguments where it is relevant.Specifically it is impossible to understand from the documentation how the override argument of sshGet change the step behavior.It would be really user friendly to explain that when override is set to false not only the local file is preserved (which is awaited, but also an exception is surprisingly raised (IllegalArgumentException... which I do not really understand... but let's admit that) with an additional error message and advice .As this exception is not really awaited, it can lead to unexpected try/catch behavior if the exact exception and its message is not checked to decide if it is a possibly awaited error (the file already exists and won't be erased) or something else more critical. _Also, the default value should be given._ Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-60156) sshGet documentation should be more explanatory about arguments behavior
Title: Message Title jlpinardon updated an issue Jenkins / JENKINS-60156 sshGet documentation should be more explanatory about arguments behavior Change By: jlpinardon Neither the [ssh step plugin documentation |https://jenkins.io/doc/pipeline/steps/ssh-steps/#sshget-ssh-steps-sshget-get-a-filedirectory-from-remote-node] nor the [ SSH Step README |https://github.com/jenkinsci/ssh-steps-plugin] file (_referenced as more detailed in the former doc !!) github project explains clearly the behavior controled by each arguments where it is relevant.Specifically it is impossible to understand from the documentation how the override argument of sshGet change the step behavior.It would be really user friendly to explain that when override is set to false not only the local file is preserved (which is awaited, but also an exception is surprisingly raised (IllegalArgumentException... which I do not really understand... but let's admit that) with an additional error message and advice .As this exception is not really awaited, it can lead to unexpected try/catch behavior if the exact exception and its message is not checked to decide if it is a possibly awaited error (the file already exists and won't be erased) or something else more critical. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-60156) sshGet documentation should be more explanatory about arguments behavior
Title: Message Title jlpinardon created an issue Jenkins / JENKINS-60156 sshGet documentation should be more explanatory about arguments behavior Issue Type: Improvement Assignee: Unassigned Components: ssh-plugin Created: 2019-11-13 14:06 Environment: [ssh plugin documentation|https://jenkins.io/doc/pipeline/steps/ssh-steps/#sshget-ssh-steps-sshget-get-a-filedirectory-from-remote-node] and github project README file Priority: Major Reporter: jlpinardon Neither the step documentation nor the SSH Step README file (_referenced as more detailed in the former doc !!) github project explains clearly the behavior controled by each arguments where it is relevant. Specifically it is impossible to understand from the documentation how the override argument of sshGet change the step behavior. It would be really user friendly to explain that when override is set to false not only the local file is preserved (which is awaited, but also an exception is surprisingly raised (IllegalArgumentException... which I do not really understand... but let's admit that) with an additional error message and advice . As this exception is not really awaited, it can lead to unexpected try/catch behavior if the exact exception and its message is not checked to decide if it is a possibly awaited error (the file already exists and won't be erased) or something else more critical.
[JIRA] (JENKINS-60156) sshGet documentation should be more explanatory about arguments behavior
Title: Message Title jlpinardon updated an issue Jenkins / JENKINS-60156 sshGet documentation should be more explanatory about arguments behavior Change By: jlpinardon Environment: [ ssh plugin documentation |https://jenkins.io/doc/pipeline/steps/ssh-steps/#sshget-ssh-steps-sshget-get-a-filedirectory-from-remote-node] and github project README file 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.203022.1573653969000.13331.1573654020232%40Atlassian.JIRA.
[JIRA] (JENKINS-60079) sshScript does not run a batch file on a windows remote
Title: Message Title jlpinardon commented on JENKINS-60079 Re: sshScript does not run a batch file on a windows remote Well, perhaps I have not been clear enough. The node is a linux machine, but the remote machine to which I want to run a file through ssh is a Windows machine. As I said, I can run the bat file on the windows machine running ssh on the command line. And the same bat file runs OK when I run two ssh steps : sshPut + sshCommand. But it fails to execute the bat with a sshScript. 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.202919.1573053717000.10181.1573059840286%40Atlassian.JIRA.
[JIRA] (JENKINS-60079) sshScript does not run a batch file on a windows remote
Title: Message Title jlpinardon created an issue Jenkins / JENKINS-60079 sshScript does not run a batch file on a windows remote Issue Type: Bug Assignee: Naresh Rayapati Components: ssh-steps-plugin Created: 2019-11-06 15:21 Environment: Jenkins master 2.164.3 on linux, linux slave as a docker image provisioned with K8S and remote Windows. Slave is connected to master through JNLP. Priority: Major Reporter: jlpinardon I create a simple batch file named script.bat with a dir command within. I want to execute it from a Linux slave using the sshScript step with : sshScript remote: remote, script:'script.bat' It fails and display a stack trace (see below). As checking steps : The same script.bat correctly runs with a ssh command executed from a git bash on my laptop. Also, it runs correctly with sshPut + sshCommand (and an awfull sleep workaround to get stdout) within a pipeline. sshScript, with a .sh file on a remote Linux machine also runs correctly Here is the trace : Also: hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from 10.225.94.76/10.225.94.76:52554 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357) at
[JIRA] (JENKINS-57765) No output returned from sshCommand
Title: Message Title jlpinardon edited a comment on JENKINS-57765 Re: No output returned from sshCommand Hello,Well, I really don't understand how you can consider this as not problematic.It is really a pain indeed !Let's consider a user who wants to make some quick trials, or even a user who tries to avoid using a shell step with some more or less complex script to simply test a ssh connection. He finds the sshCommand and thinks ok, great ! I found what I need ! I have a simple way of testing, enclosing the sshCommand within a try / catch and calling a simple uname or ls command But he is totally disappointed because ... ok, there is no problem. It seems to work, but he is not sure because he has no output. And he need the output fir this or that reason because he wants to check something.That's my use case... even worst in fact. Because my organisation wants to set a bunch of test cases to validate the ssh step in order to be sure it can be used it in production, and later on to have some regression tests when upgrading jenkins and plugins. And at the first trial, I fall into this trap._How can I say to people supporting Jenkins... hey men, that's OK. It works as a charm and everybody can use it with no worries !_So, no, it is not a cosmetic problem. It is a real one because it is more or less related to some unpredictable response time. I am not sure if 5 sec is enough. Perhaps it is less (and I loose time) perhaps it is more, and I both loose information and fail a test which is actually a success. Besides, it transfers the responsibility of ensuring the complete achievement of the step to the caller. I cannot really consider this as a normal situation. So, please, could you consider again this as bug to fix ?Thanks for your help.Best Regards Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-57765) No output returned from sshCommand
Title: Message Title jlpinardon commented on JENKINS-57765 Re: No output returned from sshCommand Hello, Well, I really don't understand how you can consider this as not problematic. It is really a pain indeed ! Let's consider a user who wants to make some quick trials, or even a user who tries to avoid using a shell step with some more or less complex script to simply test a ssh connection. He finds the sshCommand and thinks ok, great ! I found what I need ! I have a simple way of testing, enclosing the sshCommand within a try / catch and calling a simple uname or ls command. ... But he is totally disappointed because ... ok, there is no problem. It seems to work, but he is not sure because he has no output. And he need the output fir this or that reason because he wants to check something. That's my use case... even worst in fact. Because my organisation wants to set a bunch of test cases to validate the ssh step in order to be sure it can be used it in production, and later on to have some regression tests when upgrading jenkins and plugins. And at the first trial, I fall into this trap. How can I say to people supporting Jenkins... hey men, that's OK. It works as a charm and everybody can use it with no worries ! So, no, it is not a cosmetic problem. It is a real one because it is more or less related to some unpredictable response time. I am not sure if 5 sec is enough. Perhaps it is less (and I loose time) perhaps it is more, and I both loose information and fail a test which is actually a success. So, please, could you consider again this as bug to fix ? Thanks for your help. Best Regards Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-52750) dir step creates a @tmp directory at level.
Title: Message Title jlpinardon edited a comment on JENKINS-52750 Re: dir step creates a @tmp directory at level. So, if I correctly understand the answer above, the point is that Jenkins needs some space to record its own stuff when a job is running. IMHA (but perhaps there are some cases I don't imagine where it is not possible ?) the better place to do that is the _build workspace_, whatever the current working directory is. At least, jenkins is sure to be able (i.e. have rwx rights) to create its temp directory.I guess that it should not be too difficult for a jenkins code to retrieve the aboslute path of the build workspace.Besides, _as a jenkins admin_, I wouldn't still see this temporary directory once the build is achieved. _Please, let this place as clean as you found it and sweep your own dust_ ! ;). Especially given that this temp dir looks to be empty in most cases when the build is over.Best Reards Regards 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-52750) dir step creates a @tmp directory at level.
Title: Message Title jlpinardon commented on JENKINS-52750 Re: dir step creates a @tmp directory at level. So, if I correctly understand the answer above, the point is that Jenkins needs some space to record its own stuff when a job is running. IMHA (but perhaps there are some cases I don't imagine where it is not possible ?) the better place to do that is the build workspace, whatever the current working directory is. At least, jenkins is sure to be able (i.e. have rwx rights) to create its temp directory. I guess that it should not be too difficult for a jenkins code to retrieve the aboslute path of the build workspace. Besides, as a jenkins admin, I wouldn't still see this temporary directory once the build is achieved. Please, let this place as clean as you found it and sweep your own dust ! . Especially given that this temp dir looks to be empty in most cases when the build is over. Best Reards 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-47345) environment and withEnv not set some environment variables like http_proxy, https_proxy and no_proxy
Title: Message Title jlpinardon commented on JENKINS-47345 Re: environment and withEnv not set some environment variables like http_proxy, https_proxy and no_proxy I think the problem is even worst. Having no_proxy in the jenkins user environment on the slave, it disappears within the pipeline ! 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-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title jlpinardon edited a comment on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should Dear all,I want to add here a user experience. The team for which I setup the CI are really in a trouble when they see a totally yellow pipeline. They don't want to make the effort to check each stage one by one to find which is OK and which is not. I can understand that, and .. .well... users or customers are always right, isn't it ? I am afraid that the proposed stage view, with a simple red note will not help. Even if a green note is added for stage with status SUCCESS.In such a situation, have in mind that users don't want to adopt the pipeline. It is a real showstopper show-stopper . And actually, they are currently asking me to come back to something which breaks the pipeline concept._So, I don't know what is the level of complexity, but to have green (or blue) color for stages ended with success, red for NOK ones and yellow for Unstable stages would be nothing else than a must have._ That will really be user friendly and avoid headache for CI guys that must battle against upset users ;). 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-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title jlpinardon edited a comment on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should Dear all,I want to add here a user experience.The team for which I setup the CI are really in a trouble when they see a totally yellow pipeline. They don't want to make the effort to check each stage one by one to find which is OK and which is not.I can understand that, and .. .well... users or customers are always right, isn't it ?I am afraid that the proposed stage view, with a simple red note will not help. Even if a green note is added for stage with status SUCCESS.In such a situation, have in mind that users don't want to adopt the pipeline. It is a real showstopper. And actually, they are asking me to come back to something which breaks the pipeline concept. So _So , I don't know what is the evel level of complexity, but to have green (or blue) color for stages ended with success, red for NOK ones and yellow dor for Unstable stage stages would be nothing else than a must have. _ That will really be user friendly and avoid headache for CI guys that must battle agains against upset users ;). 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-55701) readProperties does not interpolate some vars
Title: Message Title
jlpinardon updated an issue
Jenkins / JENKINS-55701
readProperties does not interpolate some vars
Change By:
jlpinardon
Comment:
Let's assume I have something initialized withmyVar=${instanceGlobalVar}in the property file, myVar is used as '${instanceGlobalVar}' not interpolated in the Jenkinsfile.But if I set :myVar="${instanceGlobalVar}"in an environment \{...} block, myVar has its awaited value, i.e. the one contained in "${instanceGlobalVar}.Worst is probably that this is not systematic in the property file.
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-55701) readProperties does not interpolate some vars
Title: Message Title
jlpinardon commented on JENKINS-55701
Re: readProperties does not interpolate some vars
It looks like interpolation is made only once, i.e. is not recursed until vars are all resolved. Let's consider : A global jenkins variable aGloblaVar initialized (on the global config) as 'rootDir' var1=${aGlobalVar}/folderPath var2=${var1}/anotherPath var1 is correctly initialized, but var2 value is '${globalVar}/folderPath' and not 'rootDir/folderPath'.
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-55701) readProperties does not interpolate some vars
Title: Message Title
jlpinardon commented on JENKINS-55701
Re: readProperties does not interpolate some vars
Let's assume I have something initialized with myVar=${instanceGlobalVar} in the property file, myVar is used as '${instanceGlobalVar}' not interpolated in the Jenkinsfile. But if I set : myVar="${instanceGlobalVar}" in an environment {...} block, myVar has its awaited value, i.e. the one contained in "${instanceGlobalVar}. Worst is probably that this is not systematic in the property file.
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-55701) readProperties does not interpolate some vars
Title: Message Title
jlpinardon created an issue
Jenkins / JENKINS-55701
readProperties does not interpolate some vars
Issue Type:
Bug
Assignee:
rsandell
Components:
pipeline-utility-steps-plugin
Created:
2019-01-21 12:30
Environment:
Master and Slave run each on a centOS VM Jenkins 2.121.3 Pipeline-Utility-Steps : 2.2.0
Priority:
Critical
Reporter:
jlpinardon
I have created a property files with vars either initialized to a constant value or to another var coming from the Jenkins instance global properties. Then, I create a Jenkinsfile starting with a node block which reads the property file :
def myEnv
node {
myEnv=
readProperties( file:fileName, interpolate:true )
}
pipeline {
...
}
Most of vars are correctly set as far as I can check that their value. But few of them are not interpolated. Those I am concerned with are initialized with a global jenkins variable which is either initialized itself as a constant value or using another global variable. But some others initialized the same are correctly interpolated. So... I am a bit lost. Additionally, I tried with interpolate:false ... and surpringly the results was not worst ! It means that variables are interpolated... unless the few that are not.
[JIRA] (JENKINS-41805) Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.
Title: Message Title jlpinardon commented on JENKINS-41805 Re: Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace. +1 I have added in a post always block a set of folderDelete operation... As far as I have only one slave, it is sustainable, but it will become ugly when using a label referencing several slaves. 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-12728) new column: "Last successful artifacts"?
Title: Message Title jlpinardon commented on JENKINS-12728 Re: new column: "Last successful artifacts"? The idea just above is really excellent. I am currently setting up a mix between old style multijob and new pipeline jobs because users are in a trouble with pipeline jobs (it is actually a user experience pb). So, I use multijob to split jobs into critical parts and it would be great to have a direct access to artifacts saved by jobs within the multijob. 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-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title jlpinardon commented on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should Dear all, I want to add here a user experience. The team for which I setup the CI are really in a trouble when they see a totally yellow pipeline. They don't want to make the effort to check each stage one by one to find which is OK and which is not. I can understand that, and .. .well... users or customers are always right, isn't it ? I am afraid that the proposed stage view, with a simple red note will not help. Even if a green note is added for stage with status SUCCESS. In such a situation, have in mind that users don't want to adopt the pipeline. And actually, they are asking me to come back to something which breaks the pipeline concept. So, I don't know what is the evel of complexity, but to have green (or blue) color for stages ended with success, red for NOK ones and yellow dor Unstable stage would be nothing else than a must have. That will really be user friendly and avoid headache for CI guys that must battle agains users . 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-34469) robotframework pipeline-plugin compatibility
Title: Message Title jlpinardon commented on JENKINS-34469 Re: robotframework pipeline-plugin compatibility Hello, Sorry if it looks like I am insisting... But the (not so) cosmetic problem I reported above is so annoying for (perhaps miseducated) users that they want me to split the pipeline into two pieces because they don't clearly understand if the build (stricto sensu) is OK or not. It certainly not be a big job to do that, but it is not intellectually satisfying at all, and it breaks the pipeline concept. 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-34469) robotframework pipeline-plugin compatibility
Title: Message Title jlpinardon commented on JENKINS-34469 Re: robotframework pipeline-plugin compatibility Dear All, First of all, have a nice new year ! I have another comment about the Robot Publisher. If it sets the build as unstable, the entire build is shown as unstable, which is the awaited situtation. But, when looking at the stages, be it on classical or blue ocean interface, all stages appear as unstable. For many users, this is really annoying, because they would like to more easily determine at first glance if a stage is OK or not. Indeed, it would , not only be cosmetic, but actually much more user friendly and I would say offer better ergonomics, if the stages were let green (and tagged as Passed) unless the one where publisher is used. Or for the best (but I guess it is a bit more complex as it could need addtional confugration items) the step where robot tests are actually run. 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-34469) robotframework pipeline-plugin compatibility
Title: Message Title jlpinardon edited a comment on JENKINS-34469 Re: robotframework pipeline-plugin compatibility Dear All,First of all, have a nice new year ! I have another comment about the Robot Publisher. If it sets the build as unstable, the entire build is shown as unstable, which is the awaited situtation.But, when looking at the stages, be it on classical or blue ocean interface, all stages appear as unstable. For many users, this is really annoying, because they would like to more easily determine at first glance if a stage is OK or not.Indeed, it would , not only be cosmetic, but actually much more user friendly and I would say offer better ergonomics, if the stages were let green (and tagged as Passed) unless the one where publisher is used. Or for the best (but I guess it is a bit more complex as it could need addtional confugration items) the step where robot tests are actually run. Thanks for your help.Best RegardsJ.L.P. 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-55506) Pipeline job shows several identical link to workspace
Title: Message Title
jlpinardon created an issue
Jenkins / JENKINS-55506
Pipeline job shows several identical link to workspace
Issue Type:
Improvement
Assignee:
Unassigned
Components:
pipeline
Created:
2019-01-10 09:52
Environment:
The workspace link of a pipeline job has a link to the workspaces used in the last build. Great ! But, in a job, I can see 3 lines with a link to the same place, but with 3 different link like : ${BUILD_URL}/execution/node/number ???>/ws/ I did not know what is this number . But i nspecting the build directory, it seems that thesolution i sin the flowNodeStore.xml file. Each number on a link is related to a . followed by a label directive. E.g. 73 72 label RaspPi And for the corresponding build, I have a workspace link node/73/ws/ The same pattern applies for the two others. It would be clearer and less user disturbing to have only one link.
Priority:
Trivial
Reporter:
jlpinardon
Add Comment
[JIRA] (JENKINS-34469) robotframework pipeline-plugin compatibility
Title: Message Title jlpinardon commented on JENKINS-34469 Re: robotframework pipeline-plugin compatibility I am able to publish robot results on build page within a pipeline. But I have two questions : When the pipeline runs its some stages on one node, and some other stages (including the robot tests) on another node, how can I be sure that publishing the results as a post build action will retrieve the reports ? I haven't find how to specify that the post build robot results publication step must run a the requested node. Results don't appears on the job page. Is there a workaround to publish results on job page, or is there a plan to integrate such results in pipelines ? Thanks for your help Best Regards J.L.P. 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-53706) Fingerprinting Artifacts in a pipeline script without fingerprint plugin should be reported
Title: Message Title
jlpinardon created an issue
Jenkins / JENKINS-53706
Fingerprinting Artifacts in a pipeline script without fingerprint plugin should be reported
Issue Type:
Improvement
Assignee:
Unassigned
Components:
core
Created:
2018-09-21 12:30
Environment:
Jenkins 2.121.3 on a CentOS/7 machine.
Priority:
Trivial
Reporter:
jlpinardon
A jenkinsfile is coded with a post build artifact archiving step with fingerprinting such as :
success {
archiveArtifacts(
artifacts: "${env.JOB_BASE_NAME}_image/*.*",
fingerprint: true,
)
}
while the fingerprint plugin is not installed. The job succeed, and it is a good thing. Nevertheless, artifacts are displayed along with the fingerprint icons with a href which opens (for sure) a 404 error page. I think that when the fingerprint plugin is not installed or enabled, the icon must not be displayed, and also a message should be displayed in the console log.
[JIRA] (JENKINS-33839) Pipeline workspace is not browsable via pipeline page
Title: Message Title jlpinardon commented on JENKINS-33839 Re: Pipeline workspace is not browsable via pipeline page I'd like to give a link to the Workspace within notification email, and I find no reliable way to do it simply. Also, it is really a mess to have no Workspace link on each build page, at least as long as the workspace directory still exists. 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-52750) dir step creates a @tmp directory at level.
Title: Message Title
jlpinardon updated an issue
Jenkins / JENKINS-52750
dir step creates a @tmp directory at level.
Change By:
jlpinardon
In order to install some internal tools within {{/opt/tools}} through a Jenkins job, I have created a {{/opt/tools}} directory belonging to _{{jenkins:jenkins}}_ and where user {{jenkins}} only (the user running the slave) has rwx rights. Trying something like :{code:java}stages { steps('xyz') {dir('/opt/tools') { sh "pwd"} }}{code}Fails with an exception ending with :{code:java}java.nio.file.AccessDeniedException: /opt/tools@tmp at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) at java.nio.file.Files.createDirectory(Files.java:674) at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) at java.nio.file.Files.createDirectories(Files.java:767) at hudson.FilePath.mkdirs(FilePath.java:3098) at hudson.FilePath.access$900(FilePath.java:209) at hudson.FilePath$Mkdirs.invoke(FilePath.java:1216) at hudson.FilePath$Mkdirs.invoke(FilePath.java:1212) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2913) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748){code}It appears that Jenkins tries to create a tools@tmp directory at the same level as {{tools}}. Yet, there is absolutely no reason for the {{tools}} root directory to be writable for any user. And as far as *_{{/opt}}_* is concerned here, for sure _it must no not be writable for anybody else than root_. Additionnally, such _@tmp_ directory is not removed once the build is achieved. Even though it seems that the directory is empty, I think that Jenkins should remove it to give back a clean environment.
[JIRA] (JENKINS-27508) Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
Title: Message Title
jlpinardon edited a comment on JENKINS-27508
Re: Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
I confirm that this problem is realy annoying ! I'd like to use a build parameter named branchName as the name of the branch from which the pipeline script is extracted.!image-2018-08-17-07-20-30-640.png!I tried this : * with and without quotes * with branchName defined as a build parameter * with branchName defined in the prepare an environment for the rnu * with branchName defined as a global environment variableIn each and every cases, the result is exactly the same. The exact term "${branchName}" is used rather than the value :{{[BFA] Done. 0s}} {{hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/"${branchName}":refs/remotes/origin/"${branchName}" --prune" returned status code 128:}} \{{stdout: }} {{stderr: fatal: Couldn't find remote ref refs/heads/"${branchName}"}} Note that the quite complete help associated with the field states that an environment variable can be used ! _This is really annoying and this does not help for pipeline adoption_. Besides, this bug is classified as *critical*, so could we have an idea of a date for its resolution ?
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
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-27508) Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
Title: Message Title
jlpinardon edited a comment on JENKINS-27508
Re: Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
I confirm that this problem is realy annoying ! I'd like to use a build parameter named branchName as the name of the branch from which the pipeline script is extracted.!image-2018-08-17-07-20-30-640.png!I tried this : * with and without quotes * with branchName defined as a build parameter * with branchName defined in the prepare an environment for the rnu * with branchName defined as a global environment variableIn each and every cases, the result is exactly the same. The exact term "${branchName}" is used rather than the value :{{[BFA] Done. 0s}} {{hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/"${branchName}":refs/remotes/origin/"${branchName}" --prune" returned status code 128:}} \{{stdout: }} {{stderr: fatal: Couldn't find remote ref refs/heads/"${branchName}"}} This _This is really annoying and this does not help for pipeline adoption adoption_ . Besides, this bug is classified as *critical*, so could we have an idea of a date for its resolution ?
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
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-27508) Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
Title: Message Title
jlpinardon edited a comment on JENKINS-27508
Re: Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
I confirm that this problem is realy annoying !I'd like to use a build parameter named branchName as the name of the branch from which the pipeline script is extracted.!image-2018-08-17-07- 02- 20- 124 30-640 .png! I tried this : * with and without quotes * with branchName defined as a build parameter * with branchName defined in the prepare an environment for the rnu * with branchName defined as a global environment variableIn each and every cases, the result is exactly the same. The exact term "${branchName}" is used rather than the value :{{[BFA] Done. 0s}}{{hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/"${branchName}":refs/remotes/origin/"${branchName}" --prune" returned status code 128:}} \ {{stdout: }}{{stderr: fatal: Couldn't find remote ref refs/heads/"${branchName}"}} This is really annoying and this does not help for pipeline adoption.
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
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-27508) Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
Title: Message Title
jlpinardon commented on JENKINS-27508
Re: Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
I confirm that this problem is realy annoying ! I'd like to use a build parameter named branchName as the name of the branch from which the pipeline script is extracted. I tried this :
with and without quotes
with branchName defined as a build parameter
with branchName defined in the prepare an environment for the rnu
with branchName defined as a global environment variable
In each and every cases, the result is exactly the same. The exact term "${branchName}" is used rather than the value : [BFA] Done. 0s hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/"${branchName}":refs/remotes/origin/"${branchName}" --prune" returned status code 128: {{stdout: }} stderr: fatal: Couldn't find remote ref refs/heads/"${branchName}" This is really annoying and this does not help for pipeline adoption.
Add Comment
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)
--
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-27508) Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher
Title: Message Title jlpinardon updated an issue Jenkins / JENKINS-27508 Cannot used ENV Variable for repository url in GIT-Plugin in GIT Publisher Change By: jlpinardon Attachment: image-2018-08-17-07-02-20-124.png Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-13086) Clone to directory named for repository
Title: Message Title jlpinardon commented on JENKINS-13086 Re: Clone to directory named for repository I do not use Mutliple SCM and I only have a unique git repository. Nevertheless as a simple and dummy user I would have been glad if the git step behaved just like a git clone + git checkout (detached) command ! So, to be able to tell git to clone onto a directory named from the repository is (seems to me) indeed a very good idea !! Note that I loose some time before understanding why changing from a shell step with git clone to a git step made the job failing ! Another very good idea would have been to describe the current and very strange behavior in the step reference documentation which is (IMHO) often very light. Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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.
