[JIRA] [cli] (JENKINS-17929) Fail to run 'groovysh' in CLI due to insufficient permission
Dmitry Danilson commented on JENKINS-17929 Fail to run groovysh in CLI due to insufficient permission I've sent a pull request intended to fix this issue: https://github.com/jenkinsci/jenkins/pull/1035 . 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] [ivy] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
Dmitry Danilson commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used Note that the variable in the file name was not expanded properly. Looks like it is the root of the issue: environment variables are not passed to slave. As it was explained in this perfect comment it appears that Jenkins "Environment Variables" are not in fact environment variables - they should be called "Custom Jenkins Slave Parameters". As you could see here there is no variable called JAVA_VERSION among these so called "Environment Variables" (though they are not environment variables). So in order to get this fixed, you should define JAVA_VERSION variable using EnvInject plugin to get it injected into slave environment. I guess it should fix the issue. Let me know if it does not. 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] [ivy] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
Dmitry Danilson edited a comment on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used Note that the variable in the file name was not expanded properly. Looks like it is the root of the issue: environment variables are not passed to slave. As it was explained in this perfect comment it appears that Jenkins "Environment Variables" are not in fact environment variables - they should be called "Custom Jenkins Slave Parameters". As you could see here there is no variable called JAVA_VERSION among these so called "Environment Variables" (though they are not environment variables). So in order to get this fixed, you should define JAVA_VERSION variable using EnvInject plugin to get it injected into slave environment. See also related issues at StackOverflow: http://stackoverflow.com/questions/5818403/jenkins-hudson-environment-variables http://stackoverflow.com/questions/10625259/how-to-set-environment-variables-in-jenkins I guess it should fix the issue. Let me know if it does not. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-20473) line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification
Dmitry Danilson started work on JENKINS-20473 line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification Change By: Dmitry Danilson (23/Nov/13 5:09 AM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-20473) line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification
Dmitry Danilson commented on JENKINS-20473 line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification Parameters In order to make sure for me (and prove for you and others) that I am getting everything right, let me describe my explanation of the issue you have. So, we have 3 completely independent parameters that influence the issue: OS (either Windows or Linux); Jenkins version (only 2 variants that we have to take into account: either less or equal 1.530 or bigger than that); Line endings of request client (again only 2 variants: either CRLF or LF). Prediction So here is the table of results you are getting together with my prediction based on my understanding of the issue: OS/Version(crlf/non-crlf) =1.530 1.530 Linux Sucess/Success Error 400/JSON parsing error Windows Success/Success Error 400/JSON parsing error Please make sure that everything is as described in the table. Reasons Why it fails for Version1.530 for both OSes According to https://wiki.jenkins-ci.org/display/JENKINS/Quick+and+Simple+Security , you should either grant additional permission for anonymous users or use a suggested plugin: Anonymous read access required The preceding instructions require that anonymous users have read access to Jenkins. If you disable overall read access for anonymous users, the Build Token Root Plugin allows use of tokens. Why it works for Version=1.530 for both OSes Among the changes done after 1.530 release (see http://jenkins-ci.org/changelog for reference) there was one called "Use fine-grained permissions for node manipulation via REST API CLI (issue 18485)". It changed the way how permission check works - so you need additional effort. Why for Version1.530 for both OSes it fails with 400 Error and not 403 or 404, which looks more appropriate in case if it is permission issue? I guess it is due to multipart submission. I believe that in case if you use regular call it will return either 403 or 404 Error. Hope it helps. Feel free to post additional info in case if suggested recipe doesn't solve your issue. Until that, I am going to mark it as solved. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-20473) line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification
Dmitry Danilson edited a comment on JENKINS-20473 line-ending mismatch between the Jenkins HTTP server implementation and the HTTP specification Parameters In order to make sure for me (and prove for you and others) that I am getting everything right, let me describe my explanation of the issue you have. So, we have 3 completely independent parameters that influence the issue: OS (either Windows or Linux); Jenkins version (only 2 variants that we have to take into account: either less or equal 1.530 or bigger than that); Line endings of request client (again only 2 variants: either CRLF or LF). Prediction So here is the table of results you are getting together with my prediction based on my understanding of the issue: OS/Version(crlf/non-crlf) =1.530 1.530 Linux Sucess/Success Error 400/JSON parsing error Windows Success/Success Error 400/JSON parsing error Please make sure that everything is as described in the table. Reasons Why it fails for Version1.530 for both OSes According to https://wiki.jenkins-ci.org/display/JENKINS/Quick+and+Simple+Security , you should either grant additional permission for anonymous users or use a suggested plugin: Anonymous read access required The preceding instructions require that anonymous users have read access to Jenkins. If you disable overall read access for anonymous users, the Build Token Root Plugin allows use of tokens. Why it works for Version=1.530 for both OSes Among the changes done after 1.530 release (see http://jenkins-ci.org/changelog for reference) there was one called "Use fine-grained permissions for node manipulation via REST API CLI (issue 18485)". It changed the way how permission check works - so you need additional effort. Why for Version1.530 for both OSes it fails with 400 Error and not 403 or 404, which looks more appropriate in case if it is permission issue? I guess it is due to multipart submission. I believe that in case if you use regular call it will return either 403 or 404 Error. Hope it helps. Feel free to post additional info in case if suggested recipe doesn't solve your issue. Until that, I am going to consider it as solved. 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.
