[JIRA] [cvs] (JENKINS-18522) Cannot check out CVS module using legacy mode
John McCabe commented on JENKINS-18522 Cannot check out CVS module using legacy mode @Scott You say your issue is resolved but I just wanted to be clear; the issue you found whilst downgrading to version 1.6 of the CVS plug-in is resolved, but it doesn't get round the issue that it's impossible to us SSPI protocol with the most up-to-date version of the CVS and you're forced to use a version that's no longer supported to achieve this. Is that correct John 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] [cvs] (JENKINS-18522) Cannot check out CVS module using legacy mode
John McCabe commented on JENKINS-18522 Cannot check out CVS module using legacy mode Thanks Scott, I had just wanted to clarify on the basis that there is still a problem going forward (i.e. as described in https://issues.jenkins-ci.org/browse/JENKINS-18330) and that your eventual success was related to a rather nasty workaround of using an unsupported version of the plugin. John 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] [cvs] (JENKINS-18330) Support :ext: using external shell like Netbeans instead of only internal SSH
John McCabe commented on JENKINS-18330 Support :ext: using external shell like Netbeans instead of only internal SSH Scott Got a few questions if you don't mind... Were you already using the CVS plugin with pserver and changed to sspi like we did? If so, have you seen any obvious missing features with the 1.6 version over the 'new' version? Are you using an sspi CVSROOT or an ext one? Having looked back now at the CVS Plug-In changelog I agree, it does look like a complete rewrite; it does seem odd to do it that way without maintaining any backward compatibility! John 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] [cvs] (JENKINS-18330) Support :ext: using external shell like Netbeans instead of only internal SSH
John McCabe commented on JENKINS-18330 Support :ext: using external shell like Netbeans instead of only internal SSH I've just had a go with version 1.6. It seems, in general, to work. Problem is I've got loads of jobs with data referencing later versions of the plug-in. For the jobs that do, that I haven't modified, it can't load them at startup (seems reasonable). I manually modified the config.xml of one of them to set the CVS configuration for the 1.6 plug-in and it seems to work but Jenkins just kicks out an endless stream of exception stack traces. I presume these are related to it trying to read the build.xml from previous builds that reference the later plug-in as removing all the old build jobs seems to stop that happening. This is far from ideal 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/groups/opt_out.
[JIRA] [cvs] (JENKINS-18330) Support :ext: using external shell like Netbeans instead of only internal SSH
John McCabe commented on JENKINS-18330 Support :ext: using external shell like Netbeans instead of only internal SSH Scott No need to apologise; I just had a bit of time to go ahead and try it! We're also in the process of moving from CruiseControl.NET to Jenkins but we've used pserver for years. We were taken over recently by a large orgamnisation whose policies apparently don't allow us to use pserver any more so we've had to change our authentication to SSPI. I've only tried a small project with version 1.6 and there haven't been any changes recently but I didn't get any problem with the diffs bit. I've got it set to run in a custom workspace and I'm using the :ext: protocol rather than directly using :sspi:. John 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] [cvs] (JENKINS-18330) Support :ext: using external shell like Netbeans instead of only internal SSH
John McCabe commented on JENKINS-18330 Support :ext: using external shell like Netbeans instead of only internal SSH Yes, the point of SSPI is that you don't have passwords insecurely inserted into your Jenkins configuration but it does mean that Jenkins needs to be running as a user registered in the domain. 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] [cvs] (JENKINS-18522) Cannot check out CVS module using legacy mode
John McCabe commented on JENKINS-18522 Cannot check out CVS module using legacy mode @Scott, This may be specific to my project, but I'm using a custom workspace for my project (E:\Work\Jenkins\ModuleName) and have left the "Legacy mode" checkbox unchecked and this seems to work for me. @Michael You mention branching 1.6 and applying retrospective changes but there is another option. The reason both Scott and I have been forced into messing around with version 1.6 of the plug-in is described in https://issues.jenkins-ci.org/browse/JENKINS-18330; basically the current version doesn't support :sspi:, and doesn't provide a mechanism to use an external program to implement the :ext: protocol in the way that Netbeans itself does. It seems to only support :ext: using the built-in facilities (SSH) of the Netbeans-like client. A better option for me (and I suspect Scott and the few others who've been struggling with this issue on the Jenkins forum) would be to modify the current CVS plug-in to allow an option to use either the built-in facilities or an external program. Given that 1.6 forced the use of an external program I would assume that, once the output from the CVS commands (either from within the plug-in or from the external program) is captured then the processing would be fairly common. I imagine this would be a much simpler option than branching 1.6 and having separate versions of the plug-in. Does this sound feasible? John 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] [cvs] (JENKINS-18522) Cannot check out CVS module using legacy mode
John McCabe commented on JENKINS-18522 Cannot check out CVS module using legacy mode That would be very useful and I would be happy to give it a go. One of the things I mentioned on the other ticket is that I've got a load of jobs that, now that I've downdated to the 1.6 version of the plugin, won't even load. It would be nice to be able to update to 2.9+ and get them at least loaded so that I can reconfigure them (although I'm not sure if that's feasible!) Many thanks for your time. John 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] [cvs] (JENKINS-18330) Support :ext: using external shell like Netbeans instead of only internal SSH
John McCabe commented on JENKINS-18330 Support :ext: using external shell like Netbeans instead of only internal SSH That's interesting. I'm currently using 2.9. It seems a bit mad to have to go back to something as far back as 1.6 for this to be possible. 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] [cvs] (JENKINS-18330) Support :ext: using external shell like Netbeans instead of only internal SSH
John McCabe created JENKINS-18330 Support :ext: using external shell like Netbeans instead of only internal SSH Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: cvs Created: 13/Jun/13 10:29 AM Description: We have recently moved to using SSPI authentication on our CVS (CVSNT) system and now don't seem to be able to use the Jenkins CVS Plug-In to checkout our code. I've tried a rather large number of options to try to get this to work but nothing I do seems to change that fact that the plug-in appears to only attempt to use the internal ssh mechanism using public/private key authentication when a CVSROOT of the form :ext:user@server:/repository. The output is always something like I've added below. I'm aware that Jenkins uses the Netbeans JavaCVS client so I tried installing Netbeans to see how to get that to do the job. In the Netbeans CVS checkout there is an option to either use the Internal SSH, or use an External Shell. In the external shell box I was able to put: C:\Program Files (x86)\CVS Suite\CVSNT\extnt.exe server And it worked from that point. As you can see below I've tried adding CVS_RSH and CVS_SERVER environment variables to try to force this but it appears to have no effect. (Note that I've also tried CVS_EXE instead of CVS_SERVER, and the same without the underscore as the details on the internet are a bit inconsistent). I've set this to Major as it's quite important for us to be able to continue to use the CVS Plugin because of the integration to the change reporting on Jenkins. We can get round it using alternative methods, e.g. Ant task, Python script or whatever (hence the reason I haven't made this a Blocker) but that loses a lot of the benefit of Jenkins' built-in functionality. = Console Output 11:13:44 Started by user McCabe, John 11:13:44 EnvInject - Loading node environment variables. 11:13:44 EnvInject - Preparing an environment for the build. 11:13:44 EnvInject - Keeping Jenkins system variables. 11:13:44 EnvInject - Keeping Jenkins build variables. 11:13:44 EnvInject - Injecting as environment variables the properties content 11:13:44 CVS_RSH=C:\Program Files (x86)\CVS Suite\CVSNT\extnt.exe 11:13:44 CVS_SERVER=C:\Program Files (x86)\CVS Suite\CVSNT\cvs.exe 11:13:44 11:13:44 EnvInject - Variables injected successfully. 11:13:44 EnvInject - Injecting contributions. 11:13:44 Building in workspace E:\Work\Jenkins 11:13:44 cvs checkout -P -N -r mybranch mymodule 11:13:44 ERROR: CVS Authentication failed: null 11:13:44 org.netbeans.lib.cvsclient.connection.AuthenticationException: SSH connection failed. 11:13:44 at org.netbeans.lib.cvsclient.connection.SSHConnection.open(SSHConnection.java:141) 11:13:44 at org.netbeans.lib.cvsclient.Client$1.run(Client.java:374) 11:13:44 at java.lang.Thread.run(Unknown Source) 11:13:44 Caused by: com.jcraft.jsch.JSchException: java.io.FileNotFoundException: C:\Users\mccabe\.ssh\id_rsa (The system cannot find the path specified) 11:13:44 at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:98) 11:13:44 at com.jcraft.jsch.JSch.addIdentity(JSch.java:224) 11:13:44 at com.jcraft.jsch.JSch.addIdentity(JSch.java:218) 11:13:44 at org.netbeans.lib.cvsclient.connection.SSHConnection.open(SSHConnection.java:135) 11:13:44 ... 2 more 11:13:44 Caused by: java.io.FileNotFoundException: C:\Users\mccabe\.ssh\id_rsa (The system cannot find the path specified) 11:13:44 at java.io.FileInputStream.open(Native Method) 11:13:44 at java.io.FileInputStream.init(Unknown Source) 11:13:44 at java.io.FileInputStream.init(Unknown Source) 11:13:44 at com.jcraft.jsch.IdentityFile.newInstance(IdentityFile.java:83) 11:13:44 ... 5 more 11:13:44 ERROR: Cvs task failed 11:13:44 Finished: FAILURE Environment: Windows 7 x64 Project: Jenkins
[JIRA] (JENKINS-15801) Allow root of relative paths to be specified
John McCabe commented on JENKINS-15801 Allow root of relative paths to be specified I had a look at https://issues.jenkins-ci.org/browse/JENKINS-14064 again after your comment @Ulli; I'd seen it before when I was searching for a possible solution. It's a similar issue but, as far as I can see, solving that would be a lot more difficult than this suggestion 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-15801) Allow root of relative paths to be specified
John McCabe created JENKINS-15801 Allow root of relative paths to be specified Issue Type: Improvement Assignee: Ulli Hafner Components: warnings Created: 12/Nov/12 10:51 AM Description: Due to the way that my system is built, I've found I need to set up a custom Jenkins workspace but, in the build step, I'm launching a python script that moves to a specific location before starting to compile. Although I've got "resolve relative paths" checked it doesn't seem to be working properly; the files created in jobs/myjob/builds/date/workspace-files are all empty. I suspect this is caused by the odd way out code is built. The warnings tend to be of the form: ../../a/b/c/d/e.c:329: warning: empty body in an else-statement This is relative to the location where I run my build script, but that is somewhere down the path from the Jenkins workspace (e:\work\Jenkins). My suggestion is therefore to allow a root path to be used by the Compiler Warnings plugin when trying to resolve relative paths. If I were able to specify the root, let's say "E:\Work\Jenkins\p1\p2\p3", (where p1..p3 are replaced by my folder names) it should be easy for the warnings plugin to resolve "../../a/b/c/d/e.c" to "E:\Work\Jenkins\p1\a\b\c\d\e.c" correctly. Environment: Windows 7 Project: Jenkins Priority: Major Reporter: John McCabe 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
