[JIRA] (JENKINS-20941) Stored git credentials not used when submodule is updated
Title: Message Title Anthony Ferrari commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated Update: submodules are working for us now with the beta release. Sorry - I did not have the: "Use credentials from default remote of parent repository" checked before. Thank you! 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] [git-client-plugin] (JENKINS-20941) Stored git credentials not used when submodule is updated
Title: Message Title Anthony Ferrari commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated Thank you for the quick response! Yes, we are using SSH in the git plugin settings referencing a global credentials store in Jenkins/Manage/Credentials (username/key). SSH works fine with the git plugin except when we attempt to retrieve submodules. We have the "Recursively update submodules" checkbox checked. I can do this no problem using command line gitthe submodules are resolved ok. Any ideas? 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] [git-client-plugin] (JENKINS-20941) Stored git credentials not used when submodule is updated
Title: Message Title Anthony Ferrari commented on JENKINS-20941 Re: Stored git credentials not used when submodule is updated We have Jenkins ver. 1.596.2 with plugins: git 2.5.0-beta5 git-client 1.20.0-beta3 Unfortunately, we still see the error when retrieving submodules.: C:\git\bin\git.exe config --get remote.origin.url # timeout=10 > C:\git\bin\git.exe config --get-regexp ^submodule # timeout=10 > C:\git\bin\git.exe config --get submodule.helloivy.url # timeout=10 > C:\git\bin\git.exe submodule update --init --recursive helloivy FATAL: Command "C:\git\bin\git.exe submodule update --init --recursive helloivy" returned status code 1: stdout: stderr: Cloning into 'helloivy'... Permission denied (publickey). fatal: Could not read from remote repository. 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] [teamconcert-plugin] (JENKINS-26536) Team Concert Plugin - does not recognize load rules when determining changesets
Anthony Ferrari created JENKINS-26536 Team Concert Plugin - does not recognize load rules when determining changesets Issue Type: Bug Assignee: Unassigned Components: teamconcert-plugin Created: 21/Jan/15 8:08 PM Description: The Jenkins RTC Team Concert plugin (written by IBM) does not seem to recognize (consider) load rules when determining changesets (and therefore developers and culprits) for Jenkins jobs. It seems to use all components defined in the RTC repository workspace instead. The result is that code changes in areas OUTSIDE the Jenkins job are being identified incorrectly as changes. This would include any changes for all components in the RTC workspace. The result is that the Jenkins job triggers emails for changes not related to the Jenkins job source code. Environment: Jenkins ver. 1.532.2, any web browser, Project: Jenkins Labels: team-concert changeset Priority: Minor Reporter: Anthony Ferrari 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] (JENKINS-14044) System Groovy - Unable to cast to AbstractBuild
Anthony Ferrari created JENKINS-14044: - Summary: System Groovy - Unable to cast to AbstractBuild Key: JENKINS-14044 URL: https://issues.jenkins-ci.org/browse/JENKINS-14044 Project: Jenkins Issue Type: Bug Components: groovy, plugin Affects Versions: current Environment: Windows, Jenkins ver. 1.447.1, Groovy Plugin 1.8 OR Groovy Plugin 1.12 Reporter: Anthony Ferrari Assignee: vjuranek We just upgraded our Jenkins version from 1.424.6 1.447.1. After the upgrade, all system groovy scripts that contained the following line stopped working: AbstractBuild g_currentBuild = (AbstractBuild)Thread.currentThread().executable; When this line in the script is executed, the following stacktrace was generated: FATAL: null java.lang.StackOverflowError at org.codehaus.groovy.ast.ClassNode.redirect(ClassNode.java:178) at org.codehaus.groovy.ast.ClassNode.equals(ClassNode.java:677) at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1149) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1127) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1132) at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1152) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1127) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1132) at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1152) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1127) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1132) at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1152) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1127) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1132) at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1152) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1127) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1132) at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1152) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1127) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1132) at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1152) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1127) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1132) at org.codehaus.groovy.ast.ClassNode.genericTypeAsString(ClassNode.java:1152) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1127) at org.codehaus.groovy.ast.ClassNode.toString(ClassNode.java:1132) [...repeats until stack overflow.] We upgraded our Groovy plugin to the latest version (1.12) with the same result. We rolled back to Jenkins 1.424.6 and we do not see the error there. -- 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
