[JIRA] (JENKINS-33846) Restart pipeline from specific stage, after failure
Title: Message Title eguess74 commented on JENKINS-33846 Re: Restart pipeline from specific stage, after failure For all who wants this feature - there is a workaround: Create a "configuration job" that is a parameterized job. Fill it with the parameters that are reflecting the names of stages in the pipeline. for example (STAGE1=run/skip, STAGE2=run/skip) Use post build action trigger parameterized build to pass all those stages as parameters to the pipeline job. Use conditional build step in pipeline to determine if the step needs to be executed or not. (https://jenkins.io/blog/2017/01/19/converting-conditional-to-pipeline/) If the pipeline fails at STAGE2 you can rerun it starting from config job and you can say STAGE1=skip, STAGE2=run there are additional benefits as you can always go back to every run and see which parameters were used and so on. I hope that helps. 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] [analysis-core-plugin] (JENKINS-27548) Sporadic IOException: Failed to persist config
Title: Message Title eguess74 commented on JENKINS-27548 Re: Sporadic IOException: Failed to persist config Small update: for now the workaround of adding xercesImpl.jar to the classpath seems to be holding up. 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] [analysis-core-plugin] (JENKINS-27548) Sporadic IOException: Failed to persist config
Title: Message Title eguess74 commented on JENKINS-27548 Re: Sporadic IOException: Failed to persist config BTW can it be that this is the affecting code? https://github.com/jenkinsci/analysis-core-plugin/blob/9f8f492d2931981f91a06a8eb0123fd7d3cd1a58/src/main/java/hudson/plugins/analysis/util/SaxSetup.java#L19 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] [analysis-core-plugin] (JENKINS-27548) Sporadic IOException: Failed to persist config
Title: Message Title eguess74 edited a comment on JENKINS-27548 Re: Sporadic IOException: Failed to persist config Same thing here - the REST API fails to create a new job. The property cleanup doesn't seem to be doing anything. Jenkins 1.649 with latest analysis plugins I have restarted the server and as a workaround i have put xercesImpl.jar into the classpath basing on this entry here: https://blogs.oracle.com/mei/entry/java_lang_classnotfoundexception_org_apache as that seems to be the fastest and the only available fixI'll monitor if the workaround will stick. 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] [analysis-core-plugin] (JENKINS-27548) Sporadic IOException: Failed to persist config
Title: Message Title eguess74 commented on JENKINS-27548 Re: Sporadic IOException: Failed to persist config Same thing here - the REST API fails to create a new job. The property cleanup doesn't seem to be doing anything. Jenkins 1.649 with latest analysis plugins 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] [gerrit-trigger-plugin] (JENKINS-23152) builds getting lost due to GerritTrigger
eguess74 commented on JENKINS-23152 builds getting lost due to GerritTrigger installed the latest version - thanks for the link! Will watch it for a while... 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/d/optout.
[JIRA] [gerrit-trigger-plugin] (JENKINS-23152) builds getting lost due to GerritTrigger
eguess74 commented on JENKINS-23152 builds getting lost due to GerritTrigger @rsandell Could you please provide a link to download the HPI file? Thanks! 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/d/optout.
[JIRA] [gerrit-trigger-plugin] (JENKINS-23152) builds getting lost due to GerritTrigger
eguess74 commented on JENKINS-23152 builds getting lost due to GerritTrigger Hi, This is becoming a real mess for us as gerrit keeps referring to the builds that are not showing in the Jenkins GUI and all build numbers are getting messed up. Can the fix be somehow pushed forward? Thanks! 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/d/optout.
[JIRA] [git-plugin] (JENKINS-25878) Jenkins keeps printing Enter the passphrase for key: 'sshhashkey': for every build
eguess74 commented on JENKINS-25878 Jenkins keeps printing Enter the passphrase for key: sshhashkey: for every build Jenkins 1.578 git 2.1.2 git plugin 2.2.5 git client 1.10.1 credentials 1.9.4 gerrit plugin 2.2.1 user has .ssh folder with the SSH key configured to access gerrit no passphrase is used to generate the key, master is printing this error message; Gerrit is the SSH manager, the url for the repos is of the same format for all projects "server:/project" As there is no other info but just this cryptic error i can't say which builds are triggering this, but seems like not all of them or not everytime. "All works" means that there is no problems accessing Gerrit server and getting info from it or send info to it - i.e. configuration is correct, builds are going fine. Hope that helps 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/d/optout.
[JIRA] [git-plugin] (JENKINS-25878) Jenkins keeps printing Enter the passphrase for key: 'sshhashkey': for every build
eguess74 created JENKINS-25878 Jenkins keeps printing Enter the passphrase for key: sshhashkey: for every build Issue Type: Bug Assignee: Nicolas De Loof Components: git-plugin Created: 02/Dec/14 8:11 PM Description: The message seems to be printed to the stderr every time the new build is started. It keeps polluting the shell as it gets printed over the command line, or on top of vi. The jenkins user has all the credentials configured and it all works, but there is no passphrase used for the key to access git repos via SSH Environment: linux Project: Jenkins Priority: Minor Reporter: eguess74 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/d/optout.
[JIRA] [core] (JENKINS-17265) Builds disappearing from history
eguess74 commented on JENKINS-17265 Builds disappearing from history I'm seeing it happening right now on Jenkins 1.578 I had a build that i triggered using gerrit trigger (query and trigger gerrit patches) It appeared in the GUI, I saw it running in the the build queue, it sent an email about build being fixed, registered the result with gerrit, but no matter how i'm trying to access it the link to the build number leads to 404. Build is present on the file system as well. 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/d/optout.
[JIRA] [core] (JENKINS-17265) Builds disappearing from history
eguess74 reopened JENKINS-17265 Builds disappearing from history Change By: eguess74 (02/Dec/14 12:20 AM) Resolution: Duplicate Status: Resolved Reopened 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/d/optout.
[JIRA] [core] (JENKINS-17265) Builds disappearing from history
eguess74 commented on JENKINS-17265 Builds disappearing from history Jesse, Thanks for pointing me to the right direction! 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/d/optout.
[JIRA] [configurationslicing-plugin] (JENKINS-21225) Configuration Slicing for Editable Email Notification not working anymore with latest versions
eguess74 commented on JENKINS-21225 Configuration Slicing for Editable Email Notification not working anymore with latest versions same thing here - unable to do configuration slicing jenkins 1.578 email ext 2.38.2 and 2.39 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/d/optout.
[JIRA] [configurationslicing-plugin] (JENKINS-21225) Configuration Slicing for Editable Email Notification not working anymore with latest versions
eguess74 edited a comment on JENKINS-21225 Configuration Slicing for Editable Email Notification not working anymore with latest versions same thing here - unable to do configuration slicing config slicing - 1.38.3 jenkins 1.578 email ext 2.38.2 and 2.39 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/d/optout.
[JIRA] [promoted-builds] (JENKINS-8963) Remote API to create/delete/modify promotions
eguess74 commented on JENKINS-8963 Remote API to create/delete/modify promotions Jesse, Thank you very much for implementing this long awaited feature!! Can you please look into adding a separate permission into matrix-based security allowing to create promotions? Do you want it to be pulled into separated bug? Thanks! 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy the problem is not exactly in constant rebulds, but in the fact that when poll was set to daily and configured with the gerrit trigger the polls were happening a bit more often and they were always finding one commit as a recent change. Just because we are using the ivy build trigger and there are several projects that most of other projects are depending from it eventually was becoming full server rebuild. 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy So the only issue i have now is that on the direct push to ther repository git plugin keeps showing me only one commit in changelist even if there were more then one commits pushed. I'm not sure why it is not just taking last built revision and builds the rev-list from there to the currently checked out revision. 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/d/optout.
[JIRA] [core] (JENKINS-17569) False positive on git polling
eguess74 commented on JENKINS-17569 False positive on git polling i have this problem right now on jenkins 1.578 (https://issues.jenkins-ci.org/browse/JENKINS-24648) I don't know if this is gerrit rigger related or git plugin related, but it is very weird that simple comparison of revision number is not working properly. Please, I really need some help with that as the server starts to build non-stop. Thanks! 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy so, to clarify the last settings i have iisues with: my builds are using a parameter GERRIT_REFSPEC set to refs/heads/my_branch Git repository refspec = $GERRIT_REFSPEC Branches to build = $GERIT_BRANCH Strategy = Gerrit Trigger Gerrit event: repo plain repos name, branch plain "my_branch" We are using ivy build trigger with more than a 1000 of projects set this way Everytimte the poll is triggered it finds 1 commit and rebuilds it 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/d/optout.
[JIRA] [core] (JENKINS-17569) False positive on git polling
eguess74 commented on JENKINS-17569 False positive on git polling thanks for taking time to respond. I'll try mainling list as well. 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy what i would like to achieve is to make Jenkins to build only in case if there are changes submitted for review for branch my_branch and in case if there is a direct push into this branch. Nothing else should trigger the buid 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy had to go back to the ANT branch pattern ** as the plain branch name was not triggering properly if there is a topic added. 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 edited a comment on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy had to go back to the ANT branch pattern my_branch* as the plain branch name was not triggering properly if there is a topic added. 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy i'm curious if the conflict can be cuased by the fact taht i have gerrit event as the trigger configured together with the poll scm... 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy Currently i narrowed it down to the fact that i had gerrit event trigger configured together with the Poll scm trigger and those seem to be conflicting settings. It was causing Jenkins to poll much more often then it had to. Currently it is all quieted down and my life seems to be good again 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy well, not so shiny I'm definitely having fun with this conversation with myself... so when the poll was switched off the server calmed down and stopped repolling and rebuilding. BUt in the same time i los the ability to trigger build in case of direct push to the 'my_branch' using gerrit post-receive hook and git plugin push notification, because there is no jobs that using polling. 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/d/optout.
[JIRA] [git] (JENKINS-24546) Git plugin doesn't use environment variables when running git for polling
eguess74 commented on JENKINS-24546 Git plugin doesnt use environment variables when running git for polling I read the issue you referenced and I still think that git poll should not depend on the last used environement or node specific environment, unless it is supposed to be executed on the slave. As far as i understand git poll is supposed to be running on master only and therefore should not take into consideration any env settings but master node ones. Otherwise it is a recipe for "suddenly disappeared" ssh commands or libraries paths like in my case that are very hard to catch. 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy my last development here is to use POLL SCM but not set anything - keep it empty. That makes the hook for git plugin work and seems to not cause havoc... so far... 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/d/optout.
[JIRA] [git] (JENKINS-24546) Git plugin doesn't use environment variables when running git for polling
eguess74 commented on JENKINS-24546 Git plugin doesnt use environment variables when running git for polling I'm sorry I don't understand your last comment. The actual problem is stil there as the polling doesn't seem to be explicitly using master node settings to perform the poll - isn't it how it is supposed to behave? 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-19013) Gerrit Trigger: NPE on manual trigger
eguess74 commented on JENKINS-19013 Gerrit Trigger: NPE on manual trigger @rin_ne - yes, that fixed the issue for me, thank you. Sorry for the noise. OTOH i see this mistkae quite often in web, so may be it would make sense to maek it default selection? 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-19013) Gerrit Trigger: NPE on manual trigger
eguess74 edited a comment on JENKINS-19013 Gerrit Trigger: NPE on manual trigger @rin_ne - yes, that fixed the issue for me, thank you. Sorry for the noise. OTOH i see this mistake quite often in web, so may be it would make sense to make it default selection? 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 updated JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy Change By: eguess74 (09/Sep/14 6:35 PM) Summary: Gitpollalwaysfindschangeswhenthereis non none whenusedwithGerrittriggerstrategy 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy i will try the alternative approach recommended on the gerrit trigger plugin page: " If this does not work for you set Refspec to refs/changes/:refs/changes/ and 'Branches to build' to $GERRIT_REFSPEC." 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy i went back to the original configuration where GERRIT_REFSPEC is set to /refs/heads/my_branch and the the branches to build is set to $GERRIT_BRANCH. I limited the scope by speciying in gerrit trigger to trigger only on /my_branch/* Yet everytime when the job is polling the repo (scheduled poll) it always finds same change, for some of the project few months old ones 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy BTW it is jenkins 1.578 and latest gerrit trigger and git plugins 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-24648) Git poll always finds changes when there is none when used with Gerrit trigger strategy
eguess74 commented on JENKINS-24648 Git poll always finds changes when there is none when used with Gerrit trigger strategy tryig to set up the trigger explicitely as "my_branch" without patterns. 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/d/optout.
[JIRA] [git] (JENKINS-24546) Git plugin doesn't use environment variables when running git for polling
eguess74 commented on JENKINS-24546 Git plugin doesnt use environment variables when running git for polling Alright, i got to the end of it: the probelm as i see it was in the fact that in .bashrc for the user under which the Jenkins and the slaves are operating i had the LD_LIBRARY_PATH specified incorrectly (it was missing the folder from which git executable was linking the libraries). In this case nothing can be done in Jenkins GUI on the configuration side in order to override this varaible on the slave. It is always last thing to run before the execution of the command. So effectively i had a situation when if the job is rebuit on master node where the LD_LIBRARY_PATH was correct then the next poll of this project was successful. Now the interesting part is that as soon as the job was rebuilt on a slave with incorrrect LD_LIBRARY_PATH, then the next poll was failing! So as far as i understand this behaviour contradicts to what is claimed - git polling seems to pick up latest known environment, but not the one from master node. In order to check where the libraries are found by git executable you can run "ldd /path/to/git" It will show the list wof libraries used and where are they taken from, then if you will ovverride LD_LIBRARY_PATH and exclude one of the folders from the list it shoudl start failing with the error finding the libs. hope that helps 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/d/optout.
[JIRA] [git] (JENKINS-24546) Git plugin doesn't use environment variables when running git for polling
eguess74 created JENKINS-24546 Git plugin doesnt use environment variables when running git for polling Issue Type: Bug Assignee: Nicolas De Loof Components: git Created: 02/Sep/14 8:53 PM Description: In order to run git in our system git plugin needs LD_LIBRARY_PATH to be used and have entry pointing to the necessary libraries location. It all works fine for the builds as all the salves and master has the variable configured. But it fails to find some "so" files (like libcrypto.so) when it runs the polling and it fails. It seems that during the polling operation the environement variables are not used at all. Environment: Linux Project: Jenkins Priority: Major Reporter: eguess74 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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-19013) Gerrit Trigger: NPE on manual trigger
eguess74
commented on JENKINS-19013
Gerrit Trigger: NPE on manual trigger
i have an an NPE as well failing on the manual build with parameter GERRIT_REFSPEC set. It fails on the git rev-parse FETCH_HEAD^{commit
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/d/optout.
[JIRA] [gerrit-trigger] (JENKINS-19013) Gerrit Trigger: NPE on manual trigger
eguess74
edited a comment on JENKINS-19013
Gerrit Trigger: NPE on manual trigger
i have an an NPE as well failing on the manual build with parameter GERRIT_REFSPEC set. It fails on the git rev-parse FETCH_HEAD^{commit}
It might be necessary to pull this into another bug though...
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/d/optout.
[JIRA] [git] (JENKINS-10385) FATAL: Could not checkout null with start point after a reset --hard to remove a commit
eguess74 commented on JENKINS-10385 FATAL: Could not checkout null with start point after a reset --hard to remove a commit I think I found a good workaround for the problem: When you have a faulty commit pushed and Jenkins already built, it instead of going into the project workspace and trying to reset --hard it there do the "git reset --hard" operation from the execute shell build step. IT will find the previous build revision no problem and then this command will put the project into the state you need and record that last build revision properly. There will be no issues! I hope that helps! 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/d/optout.
[JIRA] [promoted-builds] (JENKINS-16063) Add USER_ID variable to be available at the time of promotion if promoted manually
eguess74
commented on JENKINS-16063
Add USER_ID variable to be available at the time of promotion if promoted manually
Thanks for taking care of that!
It would probably be a little bit simpler to use if it would be USER_ID and not the full name.
I needed to send email to the promotion user from promotion script and to get the address i used the following workaround:
create groovy script
import jenkins.*
import jenkins.model.*
import hudson.*
import hudson.model.*
name = args0
user = Jenkins.getInstance().getUser(name)
properties = user.getPrperties()
for (item in properties){
if (item.value instanceof hudson.tasks.Mailer.UserProperty){}
println(item.value.getAddress())
}
Then execute this during the promotion and pass the $PROMOTED_USER_NAME to get the email address for further work.
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/d/optout.
[JIRA] [promoted-builds] (JENKINS-16063) Add USER_ID variable to be available at the time of promotion if promoted manually
eguess74
edited a comment on JENKINS-16063
Add USER_ID variable to be available at the time of promotion if promoted manually
Thanks for taking care of that!
It would probably be a little bit simpler to use if it would be USER_ID and not the full name.
I needed to send email to the promotion user from promotion script and to get the address i used the following workaround:
create groovy script
import jenkins.*
import jenkins.model.*
import hudson.*
import hudson.model.*
name = args0
user = Jenkins.getInstance().getUser(name)
properties = user.getProperties()
for (item in properties){
if (item.value instanceof hudson.tasks.Mailer.UserProperty){}
println(item.value.getAddress())
}
Then execute this during the promotion and pass the $PROMOTED_USER_NAME to get the email address for further work.
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/d/optout.
[JIRA] [core] (JENKINS-19453) Slave launcher fails after NoClassDefFoundError: Could not initialize class jenkins.model.Jenkins$MasterComputer
eguess74 commented on JENKINS-19453 Slave launcher fails after NoClassDefFoundError: Could not initialize class jenkins.model.Jenkins$MasterComputer For the record I just saw this error in 1.553 One of the slaves started to fail the builds with this error and i had to disconnect it and then reconnect. That seemed to have resolved the issue for now. 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-19453) Slave launcher fails after NoClassDefFoundError: Could not initialize class jenkins.model.Jenkins$MasterComputer
eguess74 commented on JENKINS-19453 Slave launcher fails after NoClassDefFoundError: Could not initialize class jenkins.model.Jenkins$MasterComputer @Oleg Unix slave 2.33 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] [promoted-builds] (JENKINS-8963) Remote API to create/delete/modify promotions
eguess74 commented on JENKINS-8963 Remote API to create/delete/modify promotions Jesse, Do you mean that each job actually requires separate "config file", not a config object? 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] [promoted-builds] (JENKINS-8963) Remote API to create/delete/modify promotions
eguess74 assigned JENKINS-8963 to Kohsuke Kawaguchi Remote API to create/delete/modify promotions Assigning to Kohsuke to give it a push. Change By: eguess74 (15/Jul/13 10:38 PM) Assignee: KohsukeKawaguchi 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-10025) Calling rebuildDependencyGraph() in cycle
eguess74 resolved JENKINS-10025 as Fixed Calling rebuildDependencyGraph() in cycle Change By: eguess74 (10/Jul/13 9:24 PM) Status: Open Resolved Resolution: Fixed 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-10025) Calling rebuildDependencyGraph() in cycle
eguess74 commented on JENKINS-10025 Calling rebuildDependencyGraph() in cycle tested the latest master branch - the problem is gone! Thanks everybody! 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] [git] (JENKINS-10385) FATAL: Could not checkout null with start point after a reset --hard to remove a commit
eguess74 reopened JENKINS-10385 FATAL: Could not checkout null with start point after a reset --hard to remove a commit We just hit this problem with one of the jobs. The scenario was that the faulty commit was pushed to the repo, it was built in Jenkins, then it was reset --hard to previous commit and force pushed. After that the workspace was wiped out and now I can't build the job because it complains that it can't find the last built revision which it tries to start with. Jenkins 1.509, git plugin 1.1.23 Change By: eguess74 (04/Apr/13 3:50 PM) Resolution: Fixed Status: Resolved Reopened 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] [git] (JENKINS-10385) FATAL: Could not checkout null with start point after a reset --hard to remove a commit
eguess74 commented on JENKINS-10385 FATAL: Could not checkout null with start point after a reset --hard to remove a commit It seems that last built revision is retained in Jenkins memory and there is no way to force git plugin to forget it in this particular scenario other then restart the whole server or delete and recreate the project. May be we could have a link in GUI (somewhere under git polling log) allowing to reset last built revision together with performing a reset --hard on the repo where all local branches will be reset to their remote counterparts state? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16244) View.hasPeople too slow to use in sidepanel.jelly
eguess74 edited a comment on JENKINS-16244 View.hasPeople too slow to use in sidepanel.jelly We are running 1.504 and we still have problem with very long load of the main page view at times. If I specify the URL for particular job - it works fine. It also works fine for few days after restart, but then suddenly gets stuck. But the at some point releases and works fast again. We have about 800+ jobs and about 100 users This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used it seems we got to the root of the problem: Before the actual build starts Jenkins attempts to parse the ivy descriptors in order to determine which ivy modules are supposed to be built. This step doesn't exist when ivy build trigger is used, only when the ivy type job is used. This step is failing to parse ivy descriptors when running on slave as the environment variables are not passed to the slave from master. More than that - this step is not needed unless the build is specified to be incremental or the build is having modules as separate jobs. It works on master because we are specifying a default value for the JAVA_VERSION property in jenkins startup script. Interestingly enough injecting this variable into the build or slave configuration (Node proeprties) doesn't help, so it keeps failing on the slave. Therefore the issue is now broken to two parts: 1. The parsing descriptors step should not be executed if the build doesn't require it (that should solve our problem as we are not using neither incremental or separate module-job kind of builds) For that latest changes are provided here: https://github.com/jenkinsci/ivy-plugin/tree/ivy-descriptors 2. It still open question how to make this parsing step to work on a slave with this kind of variables in case of incremental build or separate module-jobs 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used I can now confirm that the build is not failing anymore on the slave as the parsing step was removed for builds not using the modules. The build still fails with the same exception if "build modules as separate jobs" or "incremental build" is selected. 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74
commented on JENKINS-15779
Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
I applied the patch to the current master and assembled the plugin - it works when running on master and fails on a slave with NPE
Parsing Ivy Descriptor Files
Error while reading the default Ivy 2.1 settings: failed to load settings from file:../custom.ivy.settings.xml: io problem while parsing config file: ../custom.ivy.settings-${ENV.JAVA_VERSION}.xml
[Ljava.lang.StackTraceElement;@10a6bf3
ERROR: Failed to parse ivy.xml files
java.io.IOException: Unable to parse ivy descriptors
at hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:530)
at hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:366)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589)
at hudson.model.Run.execute(Run.java:1516)
at hudson.model.Run.run(Run.java:1462)
at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: java.lang.NullPointerException
at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:793)
at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:742)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74
edited a comment on JENKINS-15779
Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
I applied the patch to the current master and assembled the plugin - it works when running on master and fails on a slave with NPE
Parsing Ivy Descriptor Files
Error while reading the default Ivy 2.1 settings: failed to load settings from file:../custom.ivy.settings.xml: io problem while parsing config file: ../custom.ivy.settings-${ENV.JAVA_VERSION}.xml
[Ljava.lang.StackTraceElement;@10a6bf3
ERROR: Failed to parse ivy.xml files
java.io.IOException: Unable to parse ivy descriptors
at hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:530)
at hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:366)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589)
at hudson.model.Run.execute(Run.java:1516)
at hudson.model.Run.run(Run.java:1462)
at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:282)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: java.lang.NullPointerException
at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:793)
at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:742)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 commented on JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type In our system all jobs are using the same set of ivy settings no matter where they are built (master or slave) So there is no need to specify this for every slave we have. I think probably the best way would be then to read from master by default, but make it so it can be overridden if specified for slave. Although we don't need this overriding functionality. Reading from master is sufficient. 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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 edited a comment on JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type In our system all jobs are using the same set of ivy settings no matter where they are built (master or slave) So there is no need to specify this for every slave we have. I.e. there is no "slave specific" configuration in that regard, if i understood your comment properly. 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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 commented on JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type We have the ivy settings file located on NFS, so from every host it is the same path /home/users/blahblah/path/to/ivysettings.xml So i believe this should work. 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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 commented on JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type I have locally rebased global-ivy-settings branch on top of the ivy-descriptor-env-fix as in includes master and assembled the plugin . Now the global settings seems to be working as i was able to compile a project with it, without the job based ivy settings. I couldn't verify it works for slave due to Jenkins-15779. Global Ant OPS are also very nice to have! 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used On the master the build works fine. On the slave it fails with the exception below. Same code, same project, same settings: ... Parsing Ivy Descriptor Files ERROR: Failed to parse ivy.xml files java.io.IOException : Remote call on hostname failed at hudson.remoting.Channel.call(Channel.java:673) at hudson.FilePath.act(FilePath.java:939) at hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:523) at hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:365) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589) at hudson.model.Run.execute(Run.java:1516) at hudson.model.Run.run(Run.java:1462) at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:281) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by:java.lang.ExceptionInInitializerError at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.getIvySettingsFile(IvyModuleSetBuild.java:893) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.getIvy(IvyModuleSetBuild.java:829) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:778) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:741) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by:java.lang.NullPointerException at hudson.model.Descriptor.getConfigFile(Descriptor.java:786) at hudson.model.Descriptor.load(Descriptor.java:774) at hudson.ivy.IvyModuleSet$DescriptorImpl.init(IvyModuleSet.java:769) at hudson.ivy.IvyModuleSet.clinit(IvyModuleSet.java:757) ... 13 more 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 edited a comment on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used your compilation workaround works! As for the main issue: On the master the build works fine. On the slave it fails with the exception below. Same code, same project, same settings: ... Parsing Ivy Descriptor Files ERROR: Failed to parse ivy.xml files java.io.IOException : Remote call on hostname failed at hudson.remoting.Channel.call(Channel.java:673) at hudson.FilePath.act(FilePath.java:939) at hudson.ivy.IvyModuleSetBuild$RunnerImpl.parseIvyDescriptorFiles(IvyModuleSetBuild.java:523) at hudson.ivy.IvyModuleSetBuild$RunnerImpl.doRun(IvyModuleSetBuild.java:365) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589) at hudson.model.Run.execute(Run.java:1516) at hudson.model.Run.run(Run.java:1462) at hudson.ivy.IvyModuleSetBuild.run(IvyModuleSetBuild.java:281) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by:java.lang.ExceptionInInitializerError at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.getIvySettingsFile(IvyModuleSetBuild.java:893) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.getIvy(IvyModuleSetBuild.java:829) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:778) at hudson.ivy.IvyModuleSetBuild$IvyXmlParser.call(IvyModuleSetBuild.java:741) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by:java.lang.NullPointerException at hudson.model.Descriptor.getConfigFile(Descriptor.java:786) at hudson.model.Descriptor.load(Descriptor.java:774) at hudson.ivy.IvyModuleSet$DescriptorImpl.init(IvyModuleSet.java:769) at hudson.ivy.IvyModuleSet.clinit(IvyModuleSet.java:757) ... 13 more 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74
commented on JENKINS-15779
Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
Your compilation fix doesn't seem to work:
c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:503: inconvertible types
found : hudson.model.AbstractProjectcapture#764 of ?,capture#607 of ?
required: hudson.ivy.IvyModule
env.put("IVY_MODULE_NAME", ((IvyModule) buildParent).getModuleName().name);
^
c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:504: inconvertible types
found : hudson.model.AbstractProjectcapture#113 of ?,capture#238 of ?
required: hudson.ivy.IvyModule
env.put("IVY_MODULE_ORGANISATION", ((IvyModule) buildParent).getModuleName().organisation);
^
Note: c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
2 errors
INFO
ERROR BUILD ERROR
INFO
INFO Fatal error compiling
my environment:
$ java -version
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06)
Java HotSpot(TM) Client VM (build 20.12-b01, mixed mode, sharing)
$ mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400)
Java version: 1.6.0_14
Java home: c:\Program Files\Java\jdk1.6.0_14\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 commented on JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type Could you please clarify your last comment? Also I believe you understood the problem correctly, but just to double check: Ivy build trigger has a setting to set where the ivy settings file is. This is used by all free style jobs that are using ivy build trigger. I would like to be able to specify the same thing for all builds of "ivy job" type on the server using absolute path to the ivy settings file commonly used by all projects. 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used As for the main problem, i "greped" the jenkins log: Every job has the an entry in the jenkins log file Configured Ivy using custom settings path/to/our_global_ivy_settings_file.xml I have found NO entries for the lines: Configured Ivy using default 2.1 settings Error while reading the default Ivy 2.1 settings 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74
edited a comment on JENKINS-15779
Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
We have resolved compilation problem. I don't know why I'm the only one who got this, but It seems to be a Java bug:
http://stackoverflow.com/questions/4829576/javac-error-inconvertible-types-with-generics
So if the IvyBuild.java is changed in this way it compiles OK:
diff --git a/src/main/java/hudson/ivy/IvyBuild.java b/src/main/java/hudson/ivy/IvyBuild.java
index fbe04d6..d98fb80 100644
a/src/main/java/hudson/ivy/IvyBuild.java
+++ b/src/main/java/hudson/ivy/IvyBuild.java
@@ -498,8 +498,13 @@ public class IvyBuild extends AbstractIvyBuildIvyModule, IvyBuild {
}
public void buildEnvVars(AbstractBuild?, ? build, EnvVars env) {
-env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name);
-env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation);
+//env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name);
+//env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation);
+Object o = build.getParent();
+ModuleName n = ( ( IvyModule ) o ).getModuleName() ;
+env.put("IVY_MODULE_NAME", n.name);
+env.put("IVY_MODULE_ORGANISATION", n.organisation);
+
}
}
}
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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74
edited a comment on JENKINS-15779
Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
We have resolved compilation problem. I don't know why I'm the only one who got this, but It seems to be a Java bug:
http://stackoverflow.com/questions/4829576/javac-error-inconvertible-types-with-generics
So if the IvyBuild.java is changed in this way it compiles OK:
diff --git a/src/main/java/hudson/ivy/IvyBuild.java b/src/main/java/hudson/ivy/IvyBuild.java
index fbe04d6..d98fb80 100644
--- a/src/main/java/hudson/ivy/IvyBuild.java
+++ b/src/main/java/hudson/ivy/IvyBuild.java
@@ -498,8 +498,13 @@ public class IvyBuild extends AbstractIvyBuildIvyModule, IvyBuild {
}
public void buildEnvVars(AbstractBuild?, ? build, EnvVars env) {
-env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name);
-env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation);
+//env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name);
+//env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation);
+Object o = build.getParent();
+ModuleName n = ( ( IvyModule ) o ).getModuleName() ;
+env.put("IVY_MODULE_NAME", n.name);
+env.put("IVY_MODULE_ORGANISATION", n.organisation);
+
}
}
}
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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74
commented on JENKINS-15779
Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
We have resolved compilation problem. I don't know why I'm the only one who got this, but It seems to be a Java bug:
http://stackoverflow.com/questions/4829576/javac-error-inconvertible-types-with-generics
So if the IvyBuild.java is changed in this way it compiles OK:
diff --git a/src/main/java/hudson/ivy/IvyBuild.java b/src/main/java/hudson/ivy/IvyBuild.java
index fbe04d6..d98fb80 100644
a/src/main/java/hudson/ivy/IvyBuild.java
+++ b/src/main/java/hudson/ivy/IvyBuild.java
@@ -498,8 +498,13 @@ public class IvyBuild extends AbstractIvyBuildIvyModule, IvyBuild {
}
public void buildEnvVars(AbstractBuild?, ? build, EnvVars env) {
-env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name);
-env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation);
+//env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModuleName().name);
+//env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).getModuleName().organisation);
+Object o = build.getParent();
+ModuleName n = ( ( IvyModule ) o ).getModuleName() ;
+env.put("IVY_MODULE_NAME", n.name);
+env.put("IVY_MODULE_ORGANISATION", n.organisation);
+
}
}
}
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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used Johno, If you don't mind - could you please put your logging code into a git patch that i would be able to apply to the current master branch and assemble the plugin? Thanks! 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74
edited a comment on JENKINS-15779
Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
Johno,
If you don't mind - could you please put your logging code into a git patch that i would be able to apply to the current master branch and assemble the plugin?
Thanks!
BTW currently i can't compile master branch:
c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:501: inconvertibl
e types
found : capture#764 of ?
required: hudson.ivy.IvyModule
env.put("IVY_MODULE_NAME", ((IvyModule) build.getParent()).getModule
Name().name);
^
c:\git_repos\ivy-plugin\src\main\java\hudson\ivy\IvyBuild.java:502: inconvertibl
e types
found : capture#895 of ?
required: hudson.ivy.IvyModule
env.put("IVY_MODULE_ORGANISATION", ((IvyModule) build.getParent()).g
etModuleName().organisation);
^
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
2 errors
INFO
ERROR BUILD ERROR
INFO
INFO Fatal error compiling
Embedded error: APT failed: 1
INFO
INFO Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Fatal error compiling
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:6
0)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Fatal error compiling
at org.jenkinsci.maven.plugins.hpi.AbstractCompilerMojo.execute(Abstract
CompilerMojo.java:491)
at org.jenkinsci.maven.plugins.hpi.CompilerMojo.execute(CompilerMojo.jav
a:111)
at org.jenkinsci.maven.plugins.hpi.AptMojo.execute(AptMojo.java:24)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:694)
... 17 more
Caused by: org.codehaus.plexus.compiler.CompilerException: APT failed: 1
at org.jenkinsci.maven.plugins.hpi.AptCompiler.compileInProcess(AptCompi
ler.java:66)
at org.jenkinsci.maven.plugins.hpi.AptCompiler.compile(AptCompiler.java:
50)
at org.jenkinsci.maven.plugins.hpi.AbstractCompilerMojo.execute(Abstract
CompilerMojo.java:486)
... 21 more
INFO
INFO Total time: 23 seconds
INFO Finished at: Tue Jan 08 17:57:20 EST 2013
INFO Final Memory: 49M/63M
INFO
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used May be there is a simple race condition or something like that? The fact is that the ivy settings file is specified in the job configuration. When the build starts on the master the variables contained in build.xml are already read by the time the ivy descriptors parsing step starts. On slave though it is not working that way, so the variables are not yet initialized, so the parsing step fails. Does it make any sense? 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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 commented on JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type This offer was increased to $150.00! 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used the offer was increased to $200 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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 commented on JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type This offer was increased to $100.00! 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 edited a comment on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used yes, i did - unfortunately it doesn't work. Plus it wouldn't be a good solution because in our build system the project's build.xml file is responsible for specifying the JAVA_VERSION that should be used (if not specified the system uses default one). So i would like to avoid the necessity of specifying project's JAVA_VERSION in more than one place. 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used yes, i did - unfortunately it doesn't work. Plus it would be a perfect solution because in our build system the project's build.xml file is responsible for specifying the JAVA_VERSION that should be used (if not specified the system uses default one). So i would like to avoid the necessity of specifying project's JAVA_VERSION in more than one place. 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74 commented on JENKINS-15779 Parsing ivy descriptors step fails on a slave when custom ivy settings file is used Hi everyone. I need this bug/feature so much that I'm willing to pay 100.00 bucks for it. This offer is registered at FreedomSponsors (http://www.freedomsponsors.org/core/issue/95/parsing-ivy-descriptors-step-fails-on-a-slave-when-custom-ivy-settings-file-is-used). Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too) I'll then check it out and will gladly pay up! If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors! 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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 commented on JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type Hi everyone. I need this bug/feature so much that I'm willing to pay 50.00 bucks for it. This offer is registered at FreedomSponsors (http://www.freedomsponsors.org/core/issue/96/add-ability-to-specify-custom-ivy-settings-file-in-global-configuration-for-ivy-job-type). Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too) I'll then check it out and will gladly pay up! If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors! 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
[JIRA] (JENKINS-16063) Add USER_ID variable to be available at the time of promotion it promoted manually
eguess74 updated JENKINS-16063 Add USER_ID variable to be available at the time of promotion it promoted manually Initially i thought it can be done via promoted builds plugin, but may be Build-user-var-plugin could provide this functionality as well? Change By: eguess74 (07/Dec/12 8:32 PM) Assignee: GavriilKonovalenko Description: WehavematrixsecurityandinordertoexecutepromotiononeshouldlogintoJenkinsandforcethepromotion.Weneedtoknowwhoperformedthepromotiontogeneratesomeadditionalfeedbackandsendemailtotheuser.PleaseaddaJenkinsuseridtobeavailableatthetimeofpromotionviaenvvariablelike USER_IDor PROMOTION_USER_IDwhenpromotionismanuallyforced. 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
[JIRA] (JENKINS-16063) Add USER_ID variable to be available at the time of promotion it promoted manually
eguess74 created JENKINS-16063 Add USER_ID variable to be available at the time of promotion it promoted manually Issue Type: Bug Assignee: Unassigned Components: promoted-builds Created: 06/Dec/12 10:28 PM Description: We have matrix security and in order to execute promotion one should login to Jenkins and force the promotion. We need to know who performed the promotion to generate some additional feedback and send email to the user. Please add a Jenkins user id to be available at the time of promotion via env variable like USER_ID or PROMOTION_USER_ID when promotion is manually forced. Environment: Linux Project: Jenkins Priority: Major Reporter: eguess74 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
[JIRA] (JENKINS-15774) Add ability to specify custom ivy settings file in global configuration for ivy job type
eguess74 created JENKINS-15774 Add ability to specify custom ivy settings file in global configuration for ivy job type Issue Type: New Feature Assignee: Timothy Bingaman Components: ivy Created: 08/Nov/12 4:29 PM Description: Currently there is only one way to specify custom ivy settings for ivy job type - relative path in the job. In our case we have a custom ivy settings that are used by all jobs. There should be a way to specify global custom ivy settings the same way it is done for ivy build trigger. Side note: the field inside the ivy job for ivy settings should support both relative and absolute paths Project: Jenkins Priority: Major Reporter: eguess74 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
[JIRA] (JENKINS-15775) Ivy job type should support any builders, not only ant
eguess74 created JENKINS-15775 Ivy job type should support any builders, not only ant Issue Type: New Feature Assignee: Timothy Bingaman Components: ivy Created: 08/Nov/12 4:43 PM Description: We are using a shell script that prepares some environment (variables and paths) and then starts ant with additional parameters. In current state this workflow is not supported by the ivy job type as it insists on using plain ant as the builder. The builder should be irrelevant for the ivy job as it is irrelevant for the simple job. It can require ant installation to perform its own steps, but should not limit the builder to be ant only. It can be that it requires to know if the builder is ant-based or not to allow for ant targets output in console view etc. The current work around for that: Create an arbitrary ant folder and change the content of "ant" script to actually run our script Environment: linux Project: Jenkins Priority: Major Reporter: eguess74 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
[JIRA] (JENKINS-15779) Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
eguess74
created JENKINS-15779
Parsing ivy descriptors step fails on a slave when custom ivy settings file is used
Issue Type:
Bug
Assignee:
Gregory Boissinot
Components:
envinject, ivy
Created:
08/Nov/12 8:52 PM
Description:
We have a global custom ivy settings file that is used by the Jenkins jobs, that are using Ivy build trigger to run. Due to the StackOverflowError we are trying to find a path to migrate all jobs from being free-style to ivy jobs.
The ivy settings file includes another file specific to the java version basing on the env variable JAVA_VERSION (named like extended.settings-${ENV.JAVA_VERSION})
On master node this resolves properly and parsing ivy descriptors step works properly. But the same exact build fails if running on a slave.
I tried to inject all sorts of variables using envInject plugin but it gives me the error all the time:
Error while reading the default Ivy2.1 settings: failed to load settings from file "our_global_ivy_settings_file".xml: io problem while parsing config file "extended.settings-${ENV.JAVA_VERSION}.xml"
Note that the variable in the file name was not expanded properly.
Environment:
Linux
Project:
Jenkins
Priority:
Major
Reporter:
eguess74
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
[JIRA] (JENKINS-15499) HistoryWidget/entry.jelly throws NullPointerException
eguess74 commented on JENKINS-15499 HistoryWidget/entry.jelly throws NullPointerException i confirm i can see that error in 1.486 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
[JIRA] (JENKINS-15227) changelog.xml is NOT a xml style file
eguess74 commented on JENKINS-15227 changelog.xml is NOT a xml style file It is also spamming log file with see SAXParseException complaining about "content not allowed in prolog" and failing to parse changelog.xml for some jobs 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
[JIRA] (JENKINS-15227) changelog.xml is NOT a xml style file
eguess74 commented on JENKINS-15227 changelog.xml is NOT a xml style file It seems that this error effectively prevents the full list of users being populated, therefore I'm unable to manage some users. 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
[JIRA] (JENKINS-10025) Calling rebuildDependencyGraph() in cycle
eguess74 assigned JENKINS-10025 to abayer Calling rebuildDependencyGraph() in cycle reassigned back abayer, as there is no response from Gregory Change By: eguess74 (02/Oct/12 9:40 PM) Assignee: GregoryBoissinot abayer 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
[JIRA] (JENKINS-10025) Calling rebuildDependencyGraph() in cycle
eguess74 commented on JENKINS-10025 Calling rebuildDependencyGraph() in cycle ping! 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
[JIRA] (JENKINS-14428) Provide group operations for Disable build slicer
eguess74 commented on JENKINS-14428 Provide group operations for Disable build slicer The string variant worked very well, thank you! AS for the configuration by views - We do have views and we use them to separate our hundreds of projects to groups, but even if I would want to use it - it will still require me to click through dozens of check boxes if i want to disable the whole group. Therefore "check all"/"uncheck all" still makes a lot of sense to me. What if i need to disable three/four groups?? Our job names are actually including group name (in a format of group+jobname), therefore if I would like to work with one or more groups I will now go to the string slicer, cause it has jobs listed in alphabetic order so i can manage them much easier, but never to "by view" - too many clicks. 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
[JIRA] (JENKINS-6963) CGit browser support.
eguess74 commented on JENKINS-6963 CGit browser support. works fine for us! Thanks a lot! I'm taking a liberty to close the issue. 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
[JIRA] (JENKINS-6963) CGit browser support.
eguess74 closed JENKINS-6963 as Fixed CGit browser support. Done! Change By: eguess74 (17/Jul/12 6:01 PM) Status: Resolved Closed 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
[JIRA] (JENKINS-10025) Calling rebuildDependencyGraph() in cycle
eguess74 commented on JENKINS-10025 Calling rebuildDependencyGraph() in cycle Any progress on that one, please? 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
[JIRA] (JENKINS-14428) Provide group operations for Disable build slicer
eguess74 created JENKINS-14428 Provide group operations for Disable build slicer Issue Type: Improvement Assignee: mdonohue Components: configurationslicing Created: 13/Jul/12 7:44 PM Description: Please take a look at adding three buttons to the disable build slicer configuration page: Check all, Uncheck all, Invert Selection + provide a regexp based configuration the same way as it is done to specify the jobs for the view. We have 700+ jobs - clicking through them is pain. Project: Jenkins Priority: Minor Reporter: eguess74 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
[JIRA] (JENKINS-14430) Teach cli commands disable-job and enable-job to perform group operations
eguess74 updated JENKINS-14430 Teach cli commands disable-job and enable-job to perform group operations Change By: eguess74 (13/Jul/12 8:02 PM) Description: Pleaseaddtheabilitytospecifyagroupofjobstobedisabled/enabled.wouldbeniceifitcouldunderstand * asallandfilteroutbypartofthenamemyjobmyj*+mayberegexp? 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
[JIRA] (JENKINS-14430) Teach cli commands disable-job and enable-job to perform group operations
eguess74 created JENKINS-14430 Teach cli commands disable-job and enable-job to perform group operations Issue Type: Improvement Assignee: Unassigned Components: cli Created: 13/Jul/12 8:01 PM Description: Please add the ability to specify a group of jobs to be disabled/enabled. would be nice if it could understand "" as "all" and filter out by part of the name myjob myj + may be regexp? Project: Jenkins Priority: Minor Reporter: eguess74 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
[JIRA] (JENKINS-14430) Teach cli commands disable-job and enable-job to perform group operations
eguess74 updated JENKINS-14430 Teach cli commands disable-job and enable-job to perform group operations Change By: eguess74 (13/Jul/12 8:02 PM) Description: Pleaseaddtheabilitytospecifyagroupofjobstobedisabled/enabled.wouldbeniceifitcouldunderstand * asterisk asallandfilteroutbypartofthename myjobmyj* +mayberegexp? 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
[JIRA] (JENKINS-14430) Teach cli commands disable-job and enable-job to perform group operations
eguess74 updated JENKINS-14430 Teach cli commands disable-job and enable-job to perform group operations Change By: eguess74 (13/Jul/12 8:03 PM) Description: Pleaseaddtheabilitytospecifyagroupofjobstobedisabled/enabled.wouldbeniceifitcouldunderstandasterisk (*) asallandfilteroutbypartofthenamemyjobmyj*+mayberegexp? 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
[JIRA] (JENKINS-14430) Teach cli commands disable-job and enable-job to perform group operations
eguess74 updated JENKINS-14430 Teach cli commands disable-job and enable-job to perform group operations Change By: eguess74 (13/Jul/12 8:03 PM) Description: Pleaseaddtheabilitytospecifyagroupofjobstobedisabled/enabled.wouldbeniceifitcouldunderstandasterisk (*) asallandfilteroutbypartofthenamemyjobmyj*+mayberegexp? 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
[JIRA] (JENKINS-10025) Calling rebuildDependencyGraph() in cycle
[ https://issues.jenkins-ci.org/browse/JENKINS-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eguess74 updated JENKINS-10025: --- Assignee: abayer (was: Timothy Bingaman) Andrew, I took freedom to reassign it to you hoping that you know somebody who could take a look at the problem described, as it seems that Timothy having no time to deal with it. Thanks in advance! Calling rebuildDependencyGraph() in cycle - Key: JENKINS-10025 URL: https://issues.jenkins-ci.org/browse/JENKINS-10025 Project: Jenkins Issue Type: Bug Components: ivy Reporter: vjuranek Assignee: abayer Priority: Blocker There probably possible cycle call of rebuildDependencyGraph(), Ivy calls Hudson.getInstance().rebuildDependencyGraph(); which starts following cycle: getModuleDescriptor() - recomputeModuleDescriptor() - setModuleDescriptor() - hudson.model.Hudson.rebuildDependencyGraph() which results into StackOverflowError, for whole exception, see http://groups.google.com/group/jenkinsci-users/browse_thread/thread/3c6b67b448c98379# -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
