[JIRA] [git-client] (JENKINS-20387) Timeout (10min) on git clone command
Mark Waite commented on JENKINS-20387 Timeout (10min) on git clone command @Luis, I'm sure that the current maintainer of the git plugin is more than happy to consider a pull request which would allow setting the timeout value from the user interface. 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-client] (JENKINS-20387) Timeout (10min) on git clone command
Mark Waite edited a comment on JENKINS-20387 Timeout (10min) on git clone command Luis, I'm sure that the current maintainer of the git plugin is more than happy to consider a pull request which would allow setting the timeout value from the user interface. 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-20533) Git2 plugin and HTTP-authentication fails
Mark Waite commented on JENKINS-20533 Git2 plugin and HTTP-authentication fails I've read in other bug reports that self signed certificates are a problem. I don't recall the details of the problem, only that they were a problem. The only work around I've heard is to switch protocol to something other than https. Can you use ssh instead of https? 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-client] (JENKINS-20387) Timeout (10min) on git clone command
Mark Waite commented on JENKINS-20387 Timeout (10min) on git clone command Another work around is to create a local bare clone of the git repository as a reference repository, then use the "Advanced clone behaviours" setting to refer to that reference repository. That will then only copy the new content from the remote repository, and will reference the earlier content from the existing repository. 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-20445) Git plugin timeout is too small
Mark Waite commented on JENKINS-20445 Git plugin timeout is too small If you have only 12 kb/second throughput from Jenkins to your git repository, you should probably consider cloning a bare copy of the repository to central location on the Jenkins server, then perform the clone with the "Advanced clone behaviour" to use a reference repository. That will significantly reduce the amount of data transferred from the git server to Jenkins. On my Debian Jenkins machine, I do that with: $ sudo mkdir -p /var/cache/git/mwaite $ sudo chown mwaite.mwaite /var/cache/git/mwaite $ cd /var/cache/git/mwaite $ git clone --bare https://github.com/jenkinsci/jenkins.git After that bare clone is available on the Jenkins machine, add that advanced behavior to the job and it should perform much better. 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-20445) Git plugin timeout is too small
Mark Waite edited a comment on JENKINS-20445 Git plugin timeout is too small If you have only 30 kb/second throughput from Jenkins to your git repository, you should probably consider cloning a bare copy of the repository to central location on the Jenkins server, then perform the clone with the "Advanced clone behaviour" to use a reference repository. That will significantly reduce the amount of data transferred from the git server to Jenkins. On my Debian Jenkins machine, I do that with: $ sudo mkdir -p /var/cache/git/mwaite $ sudo chown mwaite.mwaite /var/cache/git/mwaite $ cd /var/cache/git/mwaite $ git clone --bare https://github.com/jenkinsci/jenkins.git After that bare clone is available on the Jenkins machine, add that advanced behavior to the job and it should perform much better. 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-20569) Polling with excluded regions don't prevent job triggered
Mark Waite commented on JENKINS-20569 Polling with excluded regions dont prevent job triggered I attempted various combinations of patterns and could not find any pattern which would exclude all the changes in a subdirectory (like project/common). The behavior was the same for the JGit and the command line implementations. I'm reasonably confident this worked in the past, since we used it with older versions of the plugin. 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-20569) Polling with excluded regions don't prevent job triggered
Mark Waite commented on JENKINS-20569 Polling with excluded regions dont prevent job triggered Sonia, the 2.0 release was a major release which included changes to the job definition XML file. Those changes make the new data values unreadable by the old plugin. You will probably need to restore an old copy of the job definition XML file (jobs/jobname/config.xml). 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-20461) Git Plugin 2.0: fails to clone repo
Mark Waite commented on JENKINS-20461 Git Plugin 2.0: fails to clone repo Since the stack trace seems to indicate that the "prune" is what is failing, you might consider not pruning obsolete branches from the job definition. A (possibly related, though not duplicate) bug was reported earlier when pruning with a checkout to a subdirectory. Refer to JENKINS-20258. 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-20533) Git2 plugin and HTTP-authentication fails
Mark Waite commented on JENKINS-20533 Git2 plugin and HTTP-authentication fails The git plugin 2.0 now connects with the credentials plugin. You should be able to create a new credential in the "Manage Credentials" panel ( http://localhost:8080/credentials/? ), then use that credential for the https authentication with git plugin 2.0. Since this is the first release of the git plugin with support for the credentials plugin, the documentation is still sparse, but you may be able to infer how to use it without detailed documentation. 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-20585) Git plugin 2.0 prevents project deletion on Windows, changelog.xml is busy
Mark Waite created JENKINS-20585 Git plugin 2.0 prevents project deletion on Windows, changelog.xml is busy Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: git Created: 14/Nov/13 2:00 PM Description: A Jenkins project which has been created and cloned on a Windows master cannot be deleted if the changes have been viewed. It appears that the changelog.xml file is left open by the plugin, which prevents deletion of the project on Windows. Steps to duplicate the problem: Create a new free-style Jenkins project - mine was "check_git" Use the Git plugin with that project - I used https://github.com/MarkEWaite/check_git.git as my URL Build that job at least once Click the "Recent Changes" link in the project Attempt to delete the project - fails on Windows (OK on Linux) The error message reported is: jobs\check_git\builds\2013-11-14_06-58-41\changelog.xml: The process cannot access the file because it is being used by another process. Environment: Windows 7 Jenkins 1.509.4 Git plugin 2.0 Git client plugin 1.4.6 Project: Jenkins Labels: git Priority: Major Reporter: Mark Waite 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-18212) Branches get triggered for polling when we don't want them to
Mark Waite commented on JENKINS-18212 Branches get triggered for polling when we dont want them to Would you be willing to consider this a request for an enhancement, rather than a bug? I think the plugin is behaving as intended by the original author and by the current maintainer, and implementing what you want will require some new coding, and may require some new concepts in the plugin. 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-18212) Branches get triggered for polling when we don't want them to
Mark Waite commented on JENKINS-18212 Branches get triggered for polling when we dont want them to Thanks for the clarification. I believe the Git plugin intentionally polls all branches because it has a use case where users push branches to a central repository as "proposed changes", then Jenkins merges the content of those branches to an integration branch and pushes the resulting merge to the central repository. It has been referred to as "pre-tested commit" or "pre-tested merge". I like that use case very much, since it allows me to submit a change to the central repository for Jenkins evaluation, and only if Jenkins evaluates it successfully will the change be merged to the destination branch. 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-18212) Branches get triggered for polling when we don't want them to
Mark Waite commented on JENKINS-18212 Branches get triggered for polling when we dont want them to Couldn't you avoid the problem with the "Polling ignores commits from certain" functionality in the Git plugin to allow those admin work/upper level scripts to submit changes which don't impact the product? That will not prevent the polling, but it will prevent a build from being run as a result of the poll. 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-17614) Jenkins triggers builds on SCM changes although not configured
Mark Waite commented on JENKINS-17614 Jenkins triggers builds on SCM changes although not configured Can those who are encountering the problem identify anything specific about their configuration which exposes the problem? I've found that I see the problem with Git plugin 2.0 and Git client plugin 1.4.6 if I use JGit as the implementation, but I don't see the problem if I use Git command line as the implementation. I've seen the problem on all the platforms I tested, including Windows 8 x64, Windows 7 x86, Windows Home Server 2011, Debian Wheezy x64, and Debian Testing x64. I can't duplicate the problem when using the git command line implementation, yet the JGit implementation did not become widely used until after the release of Git plugin 2.0. If you can't deduce what is distinctive about your job that makes it build too frequently, would you be willing to upload sample job definitions which show the problem? The job definitions can then be compared with job definitions which do not poll too frequently in hopes there are clues in the differences between the jobs. Some questions: Does the too frequent building happen even after the workspace has been wiped? Does the too frequent building happen even on a copy of the job? Does the too frequent building happen on jobs using the git command line implementation? 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-18212) Branches get triggered for polling when we don't want them to
Mark Waite edited a comment on JENKINS-18212 Branches get triggered for polling when we dont want them to Couldn't you avoid the problem with the "Polling ignores commits from certain users" functionality in the Git plugin to allow those admin work/upper level scripts to submit changes which don't impact the product? That will not prevent the polling, but it will prevent a build from being run as a result of the poll. 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-18212) Branches get triggered for polling when we don't want them to
Mark Waite commented on JENKINS-18212 Branches get triggered for polling when we dont want them to I think you may have misunderstood the result of "Polling ignores commits from certain users". I've copied your text and inserted what I believe actually happens in bold. When any push comes from any other job it will start a poll on all jobs that are set to poll. This in turn will cause the branch to see if there are any changes but will not start the build because the commit was from a user whose commits are ignored. I am assuming you don't mind if the polling happens, but rather that you do not want the build to happen due to a push from that admin work/upper level script commit. I don't understand your second use case description. If someone pushes and you don't want their build to start that time, but you do want it to start other times, then I don't see a way to use polling to monitor that repository. Polling assumes that a change on a monitored branch is expected to perform the build. Excluded users, excluded regions, and included regions have been used in the past to prevent builds, but the case you're describing with your second use case doesn't match with any of those exclusion techniques as far as I can tell. 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-20531) Retry count not working in Git plugin 2.0
Mark Waite edited a comment on JENKINS-20531 Retry count not working in Git plugin 2.0 If the Git repository from Gerrit is mirrored to the local Git mirror and the Jenkins job is cloning from the local Git mirror, why not have the Jenkins job monitor the local git mirror? You could possibly use a post-receive hook for fast detection of new arrivals. That seems like coupling the Jenkins job to the local Git mirror, but launching it from a submission to an unmonitored repository, and expecting it to build a submission which may not yet have arrived in the local Git mirror is unnecessarily asymmetric. I'm not claiming that your report is not a bug. I think it is a bug, but it seems like you could work around that bug by monitoring the local Git repo with the Jenkins job rather than monitoring the Gerrit repo and cloning the local repo. Alternately, if clone performance is the issue due to a large repository, you could consider adding an "Advanced clone behaviors" to reference the local Git repo, but clone from the Gerrit repo. That advanced clone behavior has helped significantly reduce my clone times on Linux machines. Unfortunately, I have never foudn a way to make it work on 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 -- 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-20531) Retry count not working in Git plugin 2.0
Mark Waite commented on JENKINS-20531 Retry count not working in Git plugin 2.0 If the Git repository from Gerrit is mirrored to the local Git mirror and the Jenkins job is cloning from the local Git mirror, why not have the Jenkins job monitor the local git mirror? You could possibly use a post-receive hook for fast detection of new arrivals. That seems like coupling the Jenkins job to the local Git mirror, but launching it from a submission to an unmonitored repository, and expecting it to build a submission which may not yet have arrived in the local Git mirror is unnecessarily asymmetric. 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-16557) Git changes reported if in excluded regions
Mark Waite resolved JENKINS-16557 as Wont Fix Git changes reported if in excluded regions I've resolved this as "Won't fix". The original submitter has not commented on the note that this is the expected behavior of the git plugin. It has been 9 months since there was any activity on this bug report. Change By: Mark Waite (12/Nov/13 1:10 PM) Status: Open Resolved Resolution: WontFix 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-16557) Git changes reported if in excluded regions
Mark Waite closed JENKINS-16557 as Wont Fix Git changes reported if in excluded regions Closed because this is the expected behavior of the git plugin and the requested behavior (ignore an entire commit if it includes a change in an excluded region) is non-trivial to implement. For example, if the commit includes both changes in the excluded region, and changes elsewhere, should it be excluded or included? If the change to the excluded region is not included, how will a user ever repeat that build outside Jenkins? It would somehow be assembled from a collection of submissions which does not exist as a graph represented anywhere in the git repository. Change By: Mark Waite (12/Nov/13 1:13 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 -- 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-19994) Unable to delete workspace
Mark Waite commented on JENKINS-19994 Unable to delete workspace If by "restart a Windows node" you mean anything which stops the Java slave agent process (Windows reboot, exit the slave and restart), then you are seeing a different problem, a problem which I have not seen before and which may need a different solution. The problem I'm seeing can be resolved either by killing the slave agent process and starting it again, or by restarting the computer and starting the slave agent. 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-19994) Unable to delete workspace
Mark Waite commented on JENKINS-19994 Unable to delete workspace +Henrik, can you clarify what you mean by "simple reconnect of Jenkins on the slave"? Our slaves are started with JNLP. When the Jenkins master stops, our JNLP slaves continue running, retrying the connection to the Jenkins server. We like that, but it also means that the slave will not close the files it has open unless we explicitly kill the JNLP process. How are you starting your Windows slaves? Are the slave agent processes killed and restarted in your "simple reconnect", or are they still running and they reconnect to the master server? 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-20605) Space in URL (or %20) is parsed as Unvalid URL
Mark Waite commented on JENKINS-20605 Space in URL (or %20) is parsed as Unvalid URL Could you either create a separate bug report for the error code 203 or include the stack trace from the error code 203 so that the plugin maintainer has a better chance of investigating the problem? Part of the issue seems to be specific to the Visual Studio Online git hosting, since other https repositories (from GitHub) are able to clone successfully (at least for me). 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-20605) Space in URL (or %20) is parsed as Unvalid URL
Mark Waite commented on JENKINS-20605 Space in URL (or %20) is parsed as Unvalid URL I was able to duplicate the problem by creating a Visual Studio Online account and attempting to clone that repository. The stack trace looks like this in the log window: Started by user anonymous Building remotely on waite2011-x86 in workspace D:\J86\workspace\git-multi-cli-https-has space Cloning the remote Git repository Cloning repository https://markewaite.visualstudio.com/DefaultCollection/_git/has%20space git --version git version 1.8.1.msysgit.1 ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Could not clone https://markewaite.visualstudio.com/DefaultCollection/_git/has%20space at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:310) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:151) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:144) 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.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:63) at java.lang.Thread.run(Unknown Source) Caused by: hudson.plugins.git.GitException: Invalid URL https://markewaite.visualstudio.com/DefaultCollection/_git/has%20space at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getURLWithCrendentials(CliGitAPIImpl.java:1444) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getURLWithCrendentials(CliGitAPIImpl.java:1379) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:64) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:304) ... 11 more ERROR: null Finished: FAILURE 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-20605) Space in URL (or %20) is parsed as Unvalid URL
Mark Waite commented on JENKINS-20605 Space in URL (or %20) is parsed as Unvalid URL I'm not able to duplicate the problem with either ssh or git protocol URL's that I've created myself with both the command line and the jgit implementation. I created a base git repository on my local Debian Linux machine and was able to clone it with both git protocol and ssh protocol. GitHub maps the repository name "has space" to "has-space". I've not found a way on GitHub to create a repository name containing a space character, so I was unable to test with an https protocol repository. Is the report that it is an invalid URL issued from the job configuration page, or into the job console output while the job is running? 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-20605) Space in URL (or %20) is parsed as Unvalid URL
Mark Waite edited a comment on JENKINS-20605 Space in URL (or %20) is parsed as Unvalid URL I'm not able to duplicate the problem with either ssh or git protocol URL's that I've created myself with both the command line and the jgit implementation. I created a base git repository on my local Debian Linux machine and was able to clone it with both git protocol and ssh protocol. A "%20" in the protocol URL was interpreted correctly as a space. GitHub maps the repository name "has space" to "has-space". I've not found a way on GitHub to create a repository name containing a space character, so I was unable to test with an https protocol repository. Is the report that it is an invalid URL issued from the job configuration page, or into the job console output while the job is running? 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] [jenkow-plugin] (JENKINS-20617) CVS: Ability to exclude CVS Plugins
Mark Waite edited a comment on JENKINS-20617 CVS: Ability to exclude CVS Plugins I believe there has been steady progress on moving components from core to plugins. However, there is also a commitment to backwards compatibility which is maintained and on which many Jenkins users depend. I don't know all the details of the progress in moving components from core to plugins, but I've been the grateful beneficiary of the compatibility work which has kept me running Jenkins for many years. Could you reassign this to the Jenkins core project, rather than assigning it to the jenkow-plugin? I don't think it has any relationship to the jenkow-plugin. 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-13226) Git publisher push should not fail if there is no new changes
Mark Waite commented on JENKINS-13226 Git publisher push should not fail if there is no new changes I disagree. Marking the build as failed when the push throws an exception is the behavior I expected. If an "ignore failure" check box were allowed as an optional, non-default setting, that would be fine, but I certainly want to know if a push failed on any of the jobs I've configured. 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] [jenkow-plugin] (JENKINS-20617) CVS: Ability to exclude CVS Plugins
Mark Waite commented on JENKINS-20617 CVS: Ability to exclude CVS Plugins I believe there has been steady progress on moving components from core to plugins. However, there is also a commitment to backwards compatibility which is maintained and on which many Jenkins users depend. I don't know all the details of the progress in moving components from core to plugins, but I've been the grateful beneficiary of the compatibility work which has kept me running Jenkins for many years. 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-20625) Resurrect 'git clone --reference' in git plugin
Mark Waite resolved JENKINS-20625 as Not A Defect Resurrect git clone --reference in git plugin It is available under the "Advanced clone behaviours". You can insert a reference repository in the field there. Change By: Mark Waite (18/Nov/13 1:26 PM) Status: Open Resolved Resolution: NotADefect 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-20643) Git plugin does not work with Visual Studio Online
Mark Waite commented on JENKINS-20643 Git plugin does not work with Visual Studio Online I can duplicate the problem and believe there is a work around. If the additional behavior "Force polling using workspace" is added to the Git plugin configuration for the specific job, then I can clone my TFS repository from the Jenkins job. If I don't add the additional behavior "Force polling using workspace", then the job definition page shows the same error as described in the bug report. In both those cases, I defined a global credential with my Visual Studio Online user name and password, and used that credential in the Git plugin configuration for the job. I also can avoid that message if I embed the username and password in the Git URL, though that is much less attractive, since it places the username and password in cleartext in the job definition. 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-20643) Git plugin does not work with Visual Studio Online
Mark Waite updated JENKINS-20643 Git plugin does not work with Visual Studio Online Change By: Mark Waite (19/Nov/13 1:31 PM) Priority: Blocker Major 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-20643) Git plugin does not work with Visual Studio Online
Mark Waite edited a comment on JENKINS-20643 Git plugin does not work with Visual Studio Online I can duplicate the problem and believe there is a work around. If the additional behavior "Force polling using workspace" is added to the Git plugin configuration for the specific job, then I can clone my Visual Studio Online git repository from the Jenkins job. If I don't add the additional behavior "Force polling using workspace", then the job definition page shows the same error as described in the bug report. In both those cases, I defined a global credential with my Visual Studio Online user name and password, and used that credential in the Git plugin configuration for the job. I also can avoid that message if I embed the username and password in the Git URL, though that is much less attractive, since it places the username and password in cleartext in the job definition. 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-20643) Git plugin does not work with Visual Studio Online
Mark Waite edited a comment on JENKINS-20643 Git plugin does not work with Visual Studio Online I can duplicate the problem and believe there is a work around. If the additional behavior "Force polling using workspace" is added to the Git plugin configuration for the specific job, then I can clone my Visual Studio Online git repository from the Jenkins job. If I don't add the additional behavior "Force polling using workspace", then the job definition page shows the same error as described in the bug report until I add a global credential for Visual Studio Online. Once I've added the global credential for Visual Studio Online and referenced it in the plugin definition for that job, then the "ls-remote" message disappears on the Linux machine I'm using as master server. It may yet happen on a Windows server. In each of those cases, I defined a global credential with my Visual Studio Online user name and password, and used that credential in the Git plugin configuration for the job. I also can avoid that message if I embed the username and password in the Git URL, though that is much less attractive, since it places the username and password in cleartext in the job definition. 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-20643) Git plugin does not work with Visual Studio Online
Mark Waite edited a comment on JENKINS-20643 Git plugin does not work with Visual Studio Online I can duplicate the problem and believe there is a work around. If the additional behavior "Force polling using workspace" is added to the Git plugin configuration for the specific job, then I can clone my Visual Studio Online git repository from the Jenkins job. If I don't add the additional behavior "Force polling using workspace", then the job definition page shows the same error as described in the bug report until I add a global credential for Visual Studio Online. Once I've added the global credential for Visual Studio Online and referenced it in the plugin definition for that job, then the "ls-remote" message disappears on the Linux machine I'm using as master server. It may yet happen on a Windows server. In each of those cases, I defined a global credential with my Visual Studio Online user name and password, and used that credential in the Git plugin configuration for the job. I also can avoid that message if I embed the username and password in the Git URL, though that is much less attractive, since it places the username and password in cleartext in the job definition. The multi-configuration job which I defined with https://markewaite.visualstudio.com/DefaultCollection/_git/JENKINS-20643 as the repository and my Visual Studio Online credentials was able launch on a Windows Home Server 2011 (initial workspace), and cloned successfully on Windows 7, Windows 8.1, Windows Home Server 2011 with x64 JRE, Windows Home Server 2011 with x86 JRE, Debian Wheezy, and Debian Jessie. 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-20643) Git plugin does not work with Visual Studio Online
Mark Waite edited a comment on JENKINS-20643 Git plugin does not work with Visual Studio Online I can duplicate the problem and believe there is a work around. If the additional behavior "Force polling using workspace" is added to the Git plugin configuration for the specific job, then I can clone my Visual Studio Online git repository from the Jenkins job. If I don't add the additional behavior "Force polling using workspace", then the job definition page shows the same error as described in the bug report until I add a global credential for Visual Studio Online. Once I've added the global credential for Visual Studio Online and referenced it in the plugin definition for that job, then the "ls-remote" message disappears on the Linux machine I'm using as master server. It may yet happen on a Windows server. In each of those cases, I defined a global credential with my Visual Studio Online user name and password, and used that credential in the Git plugin configuration for the job. I also can avoid that message if I embed the username and password in the Git URL, though that is much less attractive, since it places the username and password in cleartext in the job definition. The multi-configuration job which I defined with https://markewaite.visualstudio.com/DefaultCollection/_git/JENKINS-20643 as the repository and my Visual Studio Online credentials was able launch on a Windows Home Server 2011 (initial workspace), and cloned successfully on Windows 7, Windows 8.1, Windows Home Server 2011 with x64 JRE, Windows Home Server 2011 with x86 JRE, Debian Wheezy, and Debian Jessie. I used the git command line implementation for all the job definitions up to this point. When I switched to use the JGit implementation for a new multi-configuration job definition, the clone hangs on both Windows Home Server 2011 and on Windows 7 slave agents. That needs more investigation and a separate bug report. 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-20643) Git plugin does not work with Visual Studio Online
Mark Waite edited a comment on JENKINS-20643 Git plugin does not work with Visual Studio Online I can duplicate the problem and believe there is a work around. If the additional behavior "Force polling using workspace" is added to the Git plugin configuration for the specific job, then I can clone my Visual Studio Online git repository from the Jenkins job. If I don't add the additional behavior "Force polling using workspace", then the job definition page shows the same error as described in the bug report until I add a global credential for Visual Studio Online. Once I've added the global credential for Visual Studio Online and referenced it in the plugin definition for that job, then the "ls-remote" message disappears on the Linux machine I'm using as master server. It may yet happen on a Windows server. In each of those cases, I defined a global credential with my Visual Studio Online user name and password, and used that credential in the Git plugin configuration for the job. I also can avoid that message if I embed the username and password in the Git URL, though that is much less attractive, since it places the username and password in cleartext in the job definition. The multi-configuration job which I defined with https://markewaite.visualstudio.com/DefaultCollection/_git/JENKINS-20643 as the repository and my Visual Studio Online credentials was able launch on a Windows Home Server 2011 (initial workspace), and cloned successfully on Windows 7, Windows 8.1, Windows Home Server 2011 with x64 JRE, Windows Home Server 2011 with x86 JRE, Debian Wheezy, and Debian Jessie. I used the git command line implementation for all the job definitions up to this point. When I switched to use the JGit implementation for a new multi-configuration job definition, the clone hung on both Windows Home Server 2011 and on Windows 7 slave agents. That needs more investigation and a separate bug report. 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-client] (JENKINS-20387) Timeout (10min) on git clone command
Mark Waite commented on JENKINS-20387 Timeout (10min) on git clone command You will need to remove the Git plugin 2.0 and download from https://updates.jenkins-ci.org/download/plugins/ the 1.5.0 or earlier version. I've searched the code with my limited knowledge of the plugin implementation and could not find an obvious location where the timeout was controlled. We'll probably need help from the plugin maintainer or from Kohsuke. I handled my issue with the timeout by: Disable the job which can't clone because it takes longer than the timeout Login as the Jenkins user on the machine which hosts that job Use a "git clone" command in the Jenkins workspace directory for that job to clone the repository Enable the job, and let it run I admit that is an ugly work around for the root problem, but it worked for me. 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-client] (JENKINS-20387) Timeout (10min) on git clone command
Mark Waite commented on JENKINS-20387 Timeout (10min) on git clone command Thanks for the pointer, but I don't think the implementation in the Perforce plugin will help. There is already a timeout implementation in the code path used by the Git plugin. I don't understand the code well enough to find the implementation. I assume the message that is displayed is being reported by the joinWithTimeout() method in Jenkins core since it is the only java location in the jenkins, git-plugin, and git-client-plugin directories with the string "Timeout after". Unfortunately, I can't find any callers to that method. I was hopeful that others could find that and provide a pull request for consideration. Alternately, maybe there is a better way to implement the timeout such that it will reset the timeout counter each time data is received from the external process. I thought that was how it was implemented prior to git plugin 2.0, since this problem did not appear until git plugin 2.0. 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-17614) Jenkins triggers builds on SCM changes although not configured
Mark Waite commented on JENKINS-17614 Jenkins triggers builds on SCM changes although not configured Eric, that technique does not solve it for me when using the JGit implementation. Were you using the command line implementation, or the JGit implementation with the plugin? 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-17614) Jenkins triggers builds on SCM changes although not configured
Mark Waite edited a comment on JENKINS-17614 Jenkins triggers builds on SCM changes although not configured Eric, that technique does not solve it for me when using the JGit implementation. Were you using the command line implementation, or the JGit implementation with the plugin? In my case, I wiped the workspace, and confirmed that the multiple executions were all performing a checkout of the same git version, even though they were reporting that changes were detected. 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-15103) jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace
Mark Waite reopened JENKINS-15103 jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace This was working correctly in Git plugin 1.5.0 so long as the command line implementation was used. It no longer works correctly in Git plugin 2.0, even when the command line implementation is used. Some portion of the Git plugin or Git client plugin seems to be opening a pack file and not closing it. Change By: Mark Waite (22/Nov/13 1:58 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-19994) Unable to delete workspace
Mark Waite commented on JENKINS-19994 Unable to delete workspace The bug JENKINS-15103 may be a duplicate of this bug, even though that bug was fixed in 1.5.0, since it has reappeared in 2.0. 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-15103) jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace
Mark Waite edited a comment on JENKINS-15103 jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace This was working correctly in Git plugin 1.5.0 so long as the command line implementation was used. It no longer works correctly in Git plugin 2.0, even when the command line implementation is used. Some portion of the Git plugin or Git client plugin seems to be opening a pack file and not closing it. Refer to JENKINS-19994 for a bug which may be a duplicate of this bug. 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-client] (JENKINS-20387) Timeout (10min) on git clone command
Mark Waite commented on JENKINS-20387 Timeout (10min) on git clone command Thanks for discovering that! I was mistakenly assuming that the most recent deliveries of the Git client plugin were released from the master branch. It appears they have been released from the 1.4.x branch. I assume that is because there are larger changes on the master branch which are not yet ready for release. 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-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials
Mark Waite commented on JENKINS-20356 Git CLI cannot clone on Windows using GIT_SSH to set credentials The only alternatives I've discovered have required that I switch the URL to something other than an ssh URL. 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-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials
Mark Waite commented on JENKINS-20356 Git CLI cannot clone on Windows using GIT_SSH to set credentials I believe Git plugin 1.5 worked just fine in this case, as did earlier versions of the plugin, though none of those earlier versions supported the Jenkins credentials store. You'll need to manage the credentials yourself in the job definition, without the convenience of the Jenkins credentials system. 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] [xshell] (JENKINS-20660) xshell: java.lang.NullPointerException from regex after updating to version 0.9
Mark Waite commented on JENKINS-20660 xshell: java.lang.NullPointerException from regex after updating to version 0.9 I encountered the same problem. The work around I used was to open the job definition, then save that job definition. It appears that the latest changes to the XShell plugin do not handle updates from a previously defined job as smoothly as they should. The same problem does not occur for a newly defined job, only for a job which was defined with an earlier version of the XShell plugin. 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] [xshell] (JENKINS-20660) xshell: java.lang.NullPointerException from regex after updating to version 0.9
Mark Waite updated JENKINS-20660 xshell: java.lang.NullPointerException from regex after updating to version 0.9 Change By: Mark Waite (27/Nov/13 2:45 PM) Environment: OSX10.8.5 andDebianWheezyandWindows,XShell0.9,Jenkins1.509.4andJenkins1.532.1andJenkins1.540 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] [xshell] (JENKINS-20660) xshell: java.lang.NullPointerException from regex after updating to version 0.9
Mark Waite commented on JENKINS-20660 xshell: java.lang.NullPointerException from regex after updating to version 0.9 I submitted a pull request to fix this - https://github.com/jenkinsci/xshell-plugin/pull/10 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-20767) Git plugin 2.0: Git polling causes builds even if no changes
Mark Waite commented on JENKINS-20767 Git plugin 2.0: Git polling causes builds even if no changes Are you using the JGit executable (as described in JENKINS-20286) or are you using the command line executable? The executable is selected from a drop down in the plugin configuration I've not been able to find a repeatable case to duplicate the problem when using the Git command line executable, but I see it consistently when using the JGit executable. Can you provide a repeatable set of steps which illustrate the problem (and preferably use the Git command line executable)? JENKINS-20286 provides the steps I used to show the problem with the JGit implementation. 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] [xshell] (JENKINS-20660) xshell: java.lang.NullPointerException from regex after updating to version 0.9
Mark Waite resolved JENKINS-20660 as Fixed xshell: java.lang.NullPointerException from regex after updating to version 0.9 Version 0.10 of the XShell plugin will include this fix Change By: Mark Waite (28/Nov/13 5:47 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] [git] (JENKINS-20585) Git plugin 2.0 prevents project deletion on Windows, changelog.xml is busy
Mark Waite updated JENKINS-20585 Git plugin 2.0 prevents project deletion on Windows, changelog.xml is busy Change By: Mark Waite (29/Nov/13 1:51 AM) Description: AJenkinsprojectwhichhasbeencreatedandclonedonaWindowsmastercannotbedeletedifthechangeshavebeenviewed.Itappearsthatthechangelog.xmlfileisleftopenbytheplugin,whichpreventsdeletionoftheprojectonWindows.Stepstoduplicatetheproblem:#Createanewfree-styleJenkinsproject-minewascheck_git#UsetheGitpluginwiththatproject-Iusedhttps://github.com/MarkEWaite/check_git.gitasmyURL#Buildthatjobatleastonce#ClicktheRecentChangeslinkintheproject#Attempttodeletetheproject-failsonWindows(OKonLinux)Theerrormessagereportedis:jobs\check_git\builds\2013-11-14_06-58-41\changelog.xml:Theprocesscannotaccessthefilebecauseitisbeingusedbyanotherprocess. AsimilarjobdoesnothaveanyissuedeletingonWindowswithaSubversionSCMprovider.TheissueseemstobespecifictotheGitSCMprovider. 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-15103) jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace
Mark Waite commented on JENKINS-15103 jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace The automated tests executed by "mvn install" on the git-plugin repository seem to show the same problem. When those tests are run on Linux, they pass. When the same tests are run on Windows, several of the tests fail with the message "Failed to clean up temp dirs" The tests which are failing include: Tests in error: test_checkoutBranchFailure(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_setSubmoduleUrl(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_show_revision_for_single_commit(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_getAllLogEntries(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_revListAll(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_fetch_with_updated_tag(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs 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-15103) jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace
Mark Waite edited a comment on JENKINS-15103 jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace The automated tests executed by "mvn install" on the git-plugin repository seem to show the same problem. When those tests are run on Linux, they pass. When the same tests are run on Windows, several of the tests fail with the message "Failed to clean up temp dirs" The tests which are failing include: test_checkoutBranchFailure(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_setSubmoduleUrl(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_show_revision_for_single_commit(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_getAllLogEntries(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_revListAll(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_fetch_with_updated_tag(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs 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-15103) jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace
Mark Waite edited a comment on JENKINS-15103 jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace The automated tests executed by "mvn install" on the git-plugin repository seem to show the same problem. When those tests are run on Linux, they pass. When the same tests are run on Windows, several of the tests fail with the message "Failed to clean up temp dirs" The tests which are failing include: test_checkoutBranchFailure(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_setSubmoduleUrl(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_show_revision_for_single_commit(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_getAllLogEntries(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_revListAll(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_fetch_with_updated_tag(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs Within the failure details, the message "IOException: Unable to delete ... pack" is listed. 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-15103) jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace
Mark Waite edited a comment on JENKINS-15103 jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace The automated tests executed by "mvn install" on the git-client-plugin repository seem to show the same problem. When those tests are run on Linux, they pass. When the same tests are run on Windows, several of the tests fail with the message "Failed to clean up temp dirs" The tests which are failing include: test_checkoutBranchFailure(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_setSubmoduleUrl(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_show_revision_for_single_commit(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_getAllLogEntries(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_revListAll(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_fetch_with_updated_tag(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs Within the failure details, the message "IOException: Unable to delete ... pack" is listed. 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-15103) jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace
Mark Waite edited a comment on JENKINS-15103 jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace The automated tests executed by "mvn install" on the git-client-plugin repository seem to show the same problem. When those tests are run on Linux, they pass. When the same tests are run on Windows, several of the tests fail with the message "Failed to clean up temp dirs" The tests which are failing include: test_checkoutBranchFailure(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_setSubmoduleUrl(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_show_revision_for_single_commit(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_getAllLogEntries(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_revListAll(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_fetch_with_updated_tag(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs Within the failure details, the message "IOException: Unable to delete ... pack" is listed. Note that the same unit tests pass for the command line implementation. I think that makes the current behavior different from the originally reported behavior. The original report required that there was a certain format for the branch to build, while the unit test failure shows that it will fail for any case which uses JGit as the git executable instead of using the command line as the git executable. 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-20286) JGit incorrectly reports changes detected when polling
Mark Waite updated JENKINS-20286 JGit incorrectly reports changes detected when polling Change By: Mark Waite (01/Dec/13 3:19 PM) Priority: Major Trivial Description: AJenkinsmulti-configurationjobconfiguredwiththeGitpluginusingtheJGitimplementationwillexecutethejobateachpollinginterval,evenwhentherewerenochangesonthegitrepository.Thesamejob,configuredwiththeGitpluginusingthegitcommandlineimplementationonlyexecutesthejobwhentherewerechangesinthegitrepository.TheproblemisvisiblewithbothagitprotocolrepositoryandwithaGitHubrepositoryusingthehttpsprotocol.Samplejobdefinitionswhichshowtheproblemareattached.ThejobdefinitionswithjgitintheXMLfilenameshowtheproblem.ThejobdefinitionswithcliintheXMLfilenamedonotshowtheproblem. Thereisasimpleworkaroundfortheproblem.AddtheForcepollingusingworkspacetothejobconfigurationthroughtheAdditionalBehaviourssectionofthegitpluginconfigurationforthejob. 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-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials
Mark Waite commented on JENKINS-20356 Git CLI cannot clone on Windows using GIT_SSH to set credentials @carolynvs the fix is not in Git plugin 2.0 yet. The fix is in the source code of the git-client-plugin but a version of the client plugin has not been released which includes the fix. Once that fix is released and verified, then the bug report will be "closed". It is expected that it will be fixed in git client plugin 1.4.7. 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-15418) Fails to clean windows workspace with long path
Mark Waite commented on JENKINS-15418 Fails to clean windows workspace with long path I assume you're referring to http://longpathtool.com/, a commercial product which can assist with the fundamental limitations of Windows. I don't know how that would help Jenkins, since Jenkins needs to reliably remove files with long path names, whether or not a commercial product is available. Can you describe further how you envision long path tool would work in a Jenkins environment? 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-20569) Polling with excluded regions don't prevent job triggered
Mark Waite commented on JENKINS-20569 Polling with excluded regions dont prevent job triggered Select the "Force polling using workspace" option with the "Add" button in the Git plugin section of the job configuration page. That disables remote 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/groups/opt_out.
[JIRA] [git] (JENKINS-20569) Polling with excluded regions don't prevent job triggered
Mark Waite commented on JENKINS-20569 Polling with excluded regions dont prevent job triggered I disagree that polling using workspace should be the default. Polling using workspace is significantly slower than remote polling. When we have a new feature (like fast remote polling support) that significantly improves performance, it is better to make the faster performance the default so that new users and new jobs have the benefit of the faster performance without any special actions. It is unfortunate that fast remote polling does not work in all cases, but I think it is still better to use that as the default rather than polling using workspace by default, then allowing users the option to execute faster. 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-client] (JENKINS-20387) Timeout (10min) on git clone command
Mark Waite commented on JENKINS-20387 Timeout (10min) on git clone command I'd ask the question on the Jenkins users mailing list. I don't know how to pass Java properties to the java virtual machine running as a service on Windows. There are more people using the service on the Jenkins users mailing list than there are people monitoring this bug. 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-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials
Mark Waite commented on JENKINS-20356 Git CLI cannot clone on Windows using GIT_SSH to set credentials Git client plugin 1.5.0 has released. I plan to confirm this bug is fixed in that version. 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-20258) Git plugin with checkout to subdir and prune stale branches fails all builds
Mark Waite reopened JENKINS-20258 Git plugin with checkout to subdir and prune stale branches fails all builds Git client plugin 1.5.0 was intended to fix this (based on the submission ba2ab8934), but it still fails. Steps I used to duplicate the problem with Git client plugin 1.5.0: Create a new job (I named mine git-jgit-specific-subdir-prune) Configure git repo URL https://github.com/MarkEWaite/check_git.git Add behavior to checkout to a local subdirectory Add behavior to prune stale remote tracking branches Save the job and run it Change By: Mark Waite (17/Dec/13 2:25 AM) 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-20258) Git plugin with checkout to subdir and prune stale branches fails all builds
Mark Waite edited a comment on JENKINS-20258 Git plugin with checkout to subdir and prune stale branches fails all builds Git client plugin 1.5.0 was intended to fix this (based on the submission ba2ab8934), but it still fails. Steps I used to duplicate the problem with Git client plugin 1.5.0: Create a new job (I named mine git-jgit-specific-subdir-prune) Configure git repo URL https://github.com/MarkEWaite/check_git.git Use jgit as the implementation rather than the default Add behavior to checkout to a local subdirectory Add behavior to prune stale remote tracking branches Save the job and run 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/groups/opt_out.
[JIRA] [git] (JENKINS-20258) Git plugin with checkout to subdir and prune stale branches fails all builds
Mark Waite edited a comment on JENKINS-20258 Git plugin with checkout to subdir and prune stale branches fails all builds Git client plugin 1.5.0 was intended to fix this (based on the submission ba2ab8934), but it still fails. Steps I used to duplicate the problem with Git client plugin 1.5.0: Create a new job (I named mine git-jgit-specific-subdir-prune) Configure git repo URL https://github.com/MarkEWaite/check_git.git Use jgit as the implementation rather than the default Add behavior to checkout to a local subdirectory Add behavior to prune stale remote tracking branches Save the job and run it Stack trace looks like: Building on master in workspace /var/lib/jenkins/jobs/git-jgit-specific-subdir-prune-simple/workspace Pruning obsolete local branches FATAL: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null hudson.plugins.git.GitException: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:913) at hudson.plugins.git.extensions.impl.PruneStaleBranch.beforeCheckout(PruneStaleBranch.java:31) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:858) at hudson.model.AbstractProject.checkout(AbstractProject.java:1411) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557) at hudson.model.Run.execute(Run.java:1665) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:246) Caused by: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null at org.eclipse.jgit.transport.URIish.init(URIish.java:205) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.listRemoteBranches(JGitAPIImpl.java:923) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:901) ... 10 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 -- 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-20258) Git plugin with checkout to subdir and prune stale branches fails all builds
Mark Waite edited a comment on JENKINS-20258 Git plugin with checkout to subdir and prune stale branches fails all builds Git client plugin 1.5.0 was intended to fix this (based on the submission ba2ab8934), but it still fails. Steps I used to duplicate the problem with Git client plugin 1.5.0: Create a new job (I named mine git-jgit-specific-subdir-prune) Configure git repo URL https://github.com/MarkEWaite/check_git.git Use jgit as the implementation rather than the default Add behavior to checkout to a local subdirectory Add behavior to prune stale remote tracking branches Save the job and run it Stack trace looks like: Building on master in workspace /var/lib/jenkins/jobs/git-jgit-specific-subdir-prune-simple/workspace Pruning obsolete local branches FATAL: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null hudson.plugins.git.GitException: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:913) at hudson.plugins.git.extensions.impl.PruneStaleBranch.beforeCheckout(PruneStaleBranch.java:31) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:858) at hudson.model.AbstractProject.checkout(AbstractProject.java:1411) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557) at hudson.model.Run.execute(Run.java:1665) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:246) Caused by: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null at org.eclipse.jgit.transport.URIish.init(URIish.java:205) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.listRemoteBranches(JGitAPIImpl.java:923) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:901) ... 10 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 -- 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-20258) Git plugin with checkout to subdir and prune stale branches fails all builds
Mark Waite edited a comment on JENKINS-20258 Git plugin with checkout to subdir and prune stale branches fails all builds Git client plugin 1.5.0 was intended to fix this (based on the submission ba2ab8934), but it still fails. Steps I used to duplicate the problem with Git client plugin 1.5.0: Create a new job (I named mine git-jgit-specific-subdir-prune) Configure git repo URL https://github.com/MarkEWaite/check_git.git Use jgit as the implementation rather than the default Add behavior to checkout to a local subdirectory Add behavior to prune stale remote tracking branches Save the job and run it Stack trace looks like: Building on master in workspace /var/lib/jenkins/jobs/git-jgit-specific-subdir-prune-simple/workspace Pruning obsolete local branches FATAL: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null hudson.plugins.git.GitException: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:913) at hudson.plugins.git.extensions.impl.PruneStaleBranch.beforeCheckout(PruneStaleBranch.java:31) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:858) at hudson.model.AbstractProject.checkout(AbstractProject.java:1411) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557) at hudson.model.Run.execute(Run.java:1665) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:246) Caused by: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null at org.eclipse.jgit.transport.URIish.init(URIish.java:205) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.listRemoteBranches(JGitAPIImpl.java:923) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:901) ... 10 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 -- 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-20258) Git plugin with checkout to subdir and prune stale branches fails all builds
Mark Waite
edited a comment on JENKINS-20258
Git plugin with checkout to subdir and prune stale branches fails all builds
Git client plugin 1.5.0 was intended to fix this (based on the submission ba2ab8934), but it still fails.
Steps I used to duplicate the problem with Git client plugin 1.5.0:
Create a new job (I named mine git-jgit-specific-subdir-prune)
Configure git repo URL https://github.com/MarkEWaite/check_git.git
Use jgit as the implementation rather than the default
Add behavior to checkout to a local subdirectory
Add behavior to prune stale remote tracking branches
Save the job and run it
Stack trace looks like:
{{
Building on master in workspace /var/lib/jenkins/jobs/git-jgit-specific-subdir-prune-simple/workspace
Pruning obsolete local branches
FATAL: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null
hudson.plugins.git.GitException: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null
at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:913)
at hudson.plugins.git.extensions.impl.PruneStaleBranch.beforeCheckout(PruneStaleBranch.java:31)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:858)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557)
at hudson.model.Run.execute(Run.java:1665)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:246)
Caused by: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null
at org.eclipse.jgit.transport.URIish.init(URIish.java:205)
at org.jenkinsci.plugins.gitclient.JGitAPIImpl.listRemoteBranches(JGitAPIImpl.java:923)
at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:901)
... 10 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
--
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-20258) Git plugin with checkout to subdir and prune stale branches fails all builds
Mark Waite edited a comment on JENKINS-20258 Git plugin with checkout to subdir and prune stale branches fails all builds Git client plugin 1.5.0 was intended to fix this (based on the submission ba2ab8934), but it still fails. Steps I used to duplicate the problem with Git client plugin 1.5.0: Create a new job (I named mine git-jgit-specific-subdir-prune) Configure git repo URL https://github.com/MarkEWaite/check_git.git Use jgit as the implementation rather than the default Add behavior to checkout to a local subdirectory Add behavior to prune stale remote tracking branches Save the job and run it Stack trace looks like: Building on master in workspace /var/lib/jenkins/jobs/git-jgit-specific-subdir-prune-simple/workspace Pruning obsolete local branches FATAL: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null hudson.plugins.git.GitException: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:913) at hudson.plugins.git.extensions.impl.PruneStaleBranch.beforeCheckout(PruneStaleBranch.java:31) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:858) at hudson.model.AbstractProject.checkout(AbstractProject.java:1411) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:557) at hudson.model.Run.execute(Run.java:1665) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:246) Caused by: java.net.URISyntaxException: Cannot parse Git URI-ish: The uri was empty or null at org.eclipse.jgit.transport.URIish.init(URIish.java:205) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.listRemoteBranches(JGitAPIImpl.java:923) at org.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:901) ... 10 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 -- 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-20258) Git plugin with checkout to subdir and prune stale branches fails all builds
Mark Waite
updated JENKINS-20258
Git plugin with checkout to subdir and prune stale branches fails all builds
Change By:
Mark Waite
(17/Dec/13 2:35 AM)
Description:
Iconfiguredajobwiththegit2.0plugintocheckouttoaspecificsubdirectoryandtoprunestalebranches.Thatpairofconfigurationsettingscausetheinitialgitoperationstofailwithbothgitcommandlineandjgitimplementations.Thestacktraceforthecommandlineimplementationis:
{noformat}
StartedbyuseranonymousBuildingremotelyonalan-pcinworkspaceC:\J\workspace\git-multi-subdir-prunePruningobsoletelocalbranchesFATAL:Commandconfig--getremote.origin.urlreturnedstatuscode1:stdout:stderr:hudson.plugins.git.GitException:Commandconfig--getremote.origin.urlreturnedstatuscode1:stdout:stderr: atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:940) atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:921) atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:865) atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:875) atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteUrl(CliGitAPIImpl.java:603) athudson.plugins.git.GitAPI.getRemoteUrl(GitAPI.java:61) atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.prune(CliGitAPIImpl.java:393) atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) atsun.reflect.NativeMethodAccessorImpl.invoke(UnknownSource) atsun.reflect.DelegatingMethodAccessorImpl.invoke(UnknownSource) atjava.lang.reflect.Method.invoke(UnknownSource) athudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299) athudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280) athudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239) athudson.remoting.UserRequest.perform(UserRequest.java:118) athudson.remoting.UserRequest.perform(UserRequest.java:48) athudson.remoting.Request$2.run(Request.java:326) athudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) atjava.util.concurrent.FutureTask.run(UnknownSource) atjava.util.concurrent.ThreadPoolExecutor.runWorker(UnknownSource) atjava.util.concurrent.ThreadPoolExecutor$Worker.run(UnknownSource) athudson.remoting.Engine$1$1.run(Engine.java:63) atjava.lang.Thread.run(UnknownSource)
{noformat}
Thestacktraceforthejgitimplementationis:
{noformat}
StartedbyanSCMchangeStartedbyuseranonymousBuildingremotelyonwaite2011inworkspaceD:\J\workspace\git-multi-jgit-subdir-prunePruningobsoletelocalbranchesFATAL:java.net.URISyntaxException:CannotparseGitURI-ish:Theuriwasemptyornullhudson.plugins.git.GitException:java.net.URISyntaxException:CannotparseGitURI-ish:Theuriwasemptyornull atorg.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:869) atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) atsun.reflect.NativeMethodAccessorImpl.invoke(UnknownSource) atsun.reflect.DelegatingMethodAccessorImpl.invoke(UnknownSource) atjava.lang.reflect.Method.invoke(UnknownSource) athudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299) athudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280) athudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:239) athudson.remoting.UserRequest.perform(UserRequest.java:118) athudson.remoting.UserRequest.perform(UserRequest.java:48) athudson.remoting.Request$2.run(Request.java:326) athudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) atjava.util.concurrent.FutureTask.run(UnknownSource) atjava.util.concurrent.ThreadPoolExecutor.runWorker(UnknownSource) atjava.util.concurrent.ThreadPoolExecutor$Worker.run(UnknownSource) athudson.remoting.Engine$1$1.run(Engine.java:63) atjava.lang.Thread.run(UnknownSource)Causedby:java.net.URISyntaxException:CannotparseGitURI-ish:Theuriwasemptyornull atorg.eclipse.jgit.transport.URIish.init(URIish.java:205) atorg.jenkinsci.plugins.gitclient.JGitAPIImpl.listRemoteBranches(JGitAPIImpl.java:879) atorg.jenkinsci.plugins.gitclient.JGitAPIImpl.prune(JGitAPIImpl.java:857) ...16more
{noformat}
[JIRA] [git] (JENKINS-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials
Mark Waite
updated JENKINS-20356
Git CLI cannot clone on Windows using GIT_SSH to set credentials
Change By:
Mark Waite
(17/Dec/13 2:38 AM)
Description:
AgitjobconfiguredtousethecommandlineimplementationwithGitplugin2.0andgitclientplugin1.4.6failstocloneonWindows,butsuccessfullyclonesonLinux.Theproblemseemstobethatitistryingtoconfigureanenvironment(settingSSH_PASS=echo)forthelaunchedcommand,eventhoughWindowsdoesnotusethesametechniquetopassenvironmentvariablestoaprocess.Ithinktherewasadifferentbehaviorinpriorversionsofgit-client.Icreatedthejobby:
0-
#
Configureaglobalsshcredential
1-
#
Createanewjob,restrictittoonlyrunonWindows
2-
#
UseagitsshprotocolURL(likessh://wheezy64b/var/cache/git/mwaite/bin.git)
3-
#
Selectthecorrectsshcredentialfromthedropdownlist
4-
#
Addabuildstep(IusedXShellechohelloworld)
5-
#
Savethejob
6-
#
RunthejobStacktraceonWindows:
{noformat}
StartedbyuseranonymousBuildingremotelyonalan-pcinworkspaceC:\J\workspace\git-cli-sshCloningtheremoteGitrepositoryCloningrepositoryssh://wheezy64b/var/cache/git/mwaite/bin.gitgit--versiongitversion1.8.3.msysgit.0usingGIT_SSHtosetcredentialsJenkinsERROR:Errorcloningremoterepooriginhudson.plugins.git.GitException:Couldnotclonessh://wheezy64b/var/cache/git/mwaite/bin.git atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:310) atorg.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:151) atorg.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:144) athudson.remoting.UserRequest.perform(UserRequest.java:118) athudson.remoting.UserRequest.perform(UserRequest.java:48) athudson.remoting.Request$2.run(Request.java:326) athudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) atjava.util.concurrent.FutureTask.run(UnknownSource) atjava.util.concurrent.ThreadPoolExecutor.runWorker(UnknownSource) atjava.util.concurrent.ThreadPoolExecutor$Worker.run(UnknownSource) athudson.remoting.Engine$1$1.run(Engine.java:63) atjava.lang.Thread.run(UnknownSource)Causedby:hudson.plugins.git.GitException:Commandclone--progress-ooriginssh://wheezy64b/var/cache/git/mwaite/bin.gitC:\J\workspace\git-cli-sshreturnedstatuscode128:stdout:CloningintoC:\J\workspace\git-cli-ssh...stderr:error:cannotspawnC:\Users\Alan\AppData\Local\Temp\ssh3783977685963347919.exe:Nosuchfileordirectoryfatal:unabletofork atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:981) atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:920) atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:64) atorg.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:308) ...11moreERROR:nullFinished:FAILURE
{noformat}
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-21030) Git CLI cannot clone on Windows if Git is in non-default location
Mark Waite created JENKINS-21030 Git CLI cannot clone on Windows if Git is in non-default location Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: git, git-client Created: 17/Dec/13 2:58 AM Description: The GIT_SSH fix for JENKINS-20356 only works if the Git program is installed in the default location on Windows. I had installed to a different location and had updated the PATH variable to find that non-default location. All the typical plugin operations worked, except this recently added code for JENKINS-20356 was not able to find ssh.exe. The message is misleading, since the issue is not that the plugin only supports official git client. The plugin could not find the ssh.exe program on the simple paths it checked. Unfortunately, it did not search the PATH, it only searched in the ProgramFiles directory, and I had installed to a different drive in order to save space on a small disc that was hosting ProgramFiles. Stack trace looks like this: Started by user anonymous Building remotely on alan-pc in workspace C:\J\workspace\JENKINS-20356 Cloning the remote Git repository Cloning repository ssh://wheezy64b/var/cache/git/mwaite/bin.git Fetching upstream changes from ssh://wheezy64b/var/cache/git/mwaite/bin.git using GIT_SSH to set credentials Jenkins FATAL: git plugin only support official git client http://git-scm.com/download/win java.lang.RuntimeException: git plugin only support official git client http://git-scm.com/download/win at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.createWindowsGitSSH(CliGitAPIImpl.java:1053) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:963) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:68) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:217) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:349) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145) 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.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:63) at java.lang.Thread.run(Unknown Source) Environment: Windows Git client plugin 1.5.0 Git plugin 2.0 Project: Jenkins Priority: Minor Reporter: Mark Waite 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-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials
Mark Waite closed JENKINS-20356 as Fixed Git CLI cannot clone on Windows using GIT_SSH to set credentials Confirmed closed in git client plugin 1.5.0. Change By: Mark Waite (17/Dec/13 4:26 AM) 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 -- 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-20569) Polling with excluded regions don't prevent job triggered
Mark Waite updated JENKINS-20569 Polling with excluded regions dont prevent job triggered Change By: Mark Waite (17/Dec/13 4:30 AM) Priority: Blocker Minor 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-21030) Git CLI cannot clone with ssh protocol on Windows if Git is in non-default location
Mark Waite updated JENKINS-21030 Git CLI cannot clone with ssh protocol on Windows if Git is in non-default location Change By: Mark Waite (18/Dec/13 1:46 PM) Summary: GitCLIcannotclone withsshprotocol onWindowsifGitisinnon-defaultlocation 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-20767) Git plugin 2.0: Git polling causes builds even if no changes
Mark Waite commented on JENKINS-20767 Git plugin 2.0: Git polling causes builds even if no changes Corey O'Connor when you say "confirmed" do you mean that you used command line or that you used jgit? 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-20461) Git Plugin 2.0: fails to clone repo
Mark Waite resolved JENKINS-20461 as Duplicate Git Plugin 2.0: fails to clone repo Duplicate of JENKINS-20258 Change By: Mark Waite (19/Dec/13 9:45 PM) Status: Open Resolved Resolution: Duplicate 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-20461) Git Plugin 2.0: fails to clone repo
Mark Waite commented on JENKINS-20461 Git Plugin 2.0: fails to clone repo It seems like "don't prune the local branches" is an easy work around. Are there serious problems if you don't prune the local branches? 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-20195) Git plugin fails to checkout master branch on remote slave
Mark Waite resolved JENKINS-20195 as Fixed Git plugin fails to checkout master branch on remote slave Confirmed the bug is fixed. I used the steps I listed to attempt to duplicate the bug with Git plugin 2.0 and git client plugin 1.6.0. Change By: Mark Waite (21/Dec/13 12:59 PM) Status: Open Resolved Fix Version/s: current 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] [git] (JENKINS-20195) Git plugin fails to checkout master branch on remote slave
Mark Waite closed JENKINS-20195 as Fixed Git plugin fails to checkout master branch on remote slave Verified resolved in git client plugin 1.6.0. Change By: Mark Waite (21/Dec/13 12:59 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 -- 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-15103) jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace
Mark Waite edited a comment on JENKINS-15103 jenkins slave process does not let go of .git\objects\pack\*.pack file causeing Unable to delete when wiping workspace The automated tests executed by "mvn install" on the git-client-plugin repository seem to show the same problem. When those tests are run on Linux, they pass. When the same tests are run on Windows, several of the tests fail with the message "Failed to clean up temp dirs" The tests which are failing include: test_checkoutBranchFailure(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_setSubmoduleUrl(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_show_revision_for_single_commit(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_getAllLogEntries(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_revListAll(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs test_fetch_with_updated_tag(org.jenkinsci.plugins.gitclient.JGitAPIImplTest): Failed to clean up temp dirs Within the failure details, the message "IOException: Unable to delete ... pack" is listed. Note that the same unit tests pass for the command line implementation. I think that makes the current behavior different from the originally reported behavior. The original report required that there was a certain format for the branch to build, while the unit test failure shows that it will fail for any case which uses JGit as the git executable instead of using the command line as the git executable. Unfortunately, those test failures only happen in the JGit implementation, not in the CLI implementation. This bug report was submitted confirmed as a problem with both the JGit and the CLI implementations, so fixing the JGit specific test failures will not be enough. 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-21114) Cannot use reference clone option against a bare repository
Mark Waite commented on JENKINS-21114 Cannot use reference clone option against a bare repository Will, thanks for the proposed patch. Would you be willing to submit the change as a pull request on GitHub so that the git plugin maintainer can consider it for inclusion in a future release of the Git client plugin? 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-21114) Cannot use reference clone option against a bare repository
Mark Waite commented on JENKINS-21114 Cannot use reference clone option against a bare repository Also, is there a way to write a unit test which would show the problem (as you discovered it) and which would confirm that the problem is fixed (and stays fixed, and runs on all platforms, etc.)? 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-19994) Unable to delete workspace
Mark Waite commented on JENKINS-19994 Unable to delete workspace The leaked files plugin (run on Debian Linux) showed at least one leaked file handle from the RevWalk allocated in the ChangelogCommand of the JGit implementation. I've created a series of changes which were able to fix the condition detected by the leaked files plugin, but still did not allow me to delete the workspace on my Windows machine. I assume the fixes to the issues detected by the leaked files plugin are a necessary part of the final fix, but they are not sufficient to fix the problem on Windows. Unfortunately, I don't know how to run the leaked files plugin on Windows, it fails to execute there. If you'd like to see my current prototype (not yet ready for a pull request), refer to https://github.com/MarkEWaite/git-client-plugin/tree/JENKINS-19994-cannot-delete-jgit-workspace 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-19994) Unable to delete workspace
Mark Waite started work on JENKINS-19994 Unable to delete workspace Change By: Mark Waite (28/Dec/13 4:10 AM) Status: Open InProgress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [git] (JENKINS-19994) Unable to delete workspace
Mark Waite assigned JENKINS-19994 to Mark Waite Unable to delete workspace Change By: Mark Waite (28/Dec/13 4:10 AM) Assignee: MarkWaite 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-20445) Git plugin timeout is too small
Mark Waite commented on JENKINS-20445 Git plugin timeout is too small Refer to JENKINS-20387 for instructions on how to set the timeout. I think this report is a duplicate of JENKINS-20387. 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-20356) Git CLI cannot clone on Windows using GIT_SSH to set credentials
Mark Waite commented on JENKINS-20356 Git CLI cannot clone on Windows using GIT_SSH to set credentials I was able to confirm Hallvard's report that when running Jenkins as a service, it is unable to checkout if the Git URL uses ssh:// (like ssh://wheezy64/var/lib/git/mwaite/bin.git ). I am still able to checkout if the Git URL uses ssh protocol without the ssh:(like g...@github.com:MarkEWaite/jenkins-demo.git ). I am still able to checkout if Jenkins is not running as a service, even when it uses an ssh:// URL. It requires both that it is running as a service and that it is using ssh: protocol. 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-20585) Git plugin 2.0 prevents project deletion on Windows, changelog.xml is busy
Mark Waite commented on JENKINS-20585 Git plugin 2.0 prevents project deletion on Windows, changelog.xml is busy While researching another open file leak with the file leak detector plugin, I discovered this portion of a stack trace which seems to show where the changelog.xml file is opened and then is not closed: #7 /var/lib/jenkins/jobs/git-client-plugin-jgit/builds/2014-01-04_10-07-04/changelog.xml by thread:Handling GET /job/git-client-plugin-jgit/changes : RequestHandlerThread[#3] on Sat Jan 04 10:07:10 MST 2014 at java.io.FileInputStream.init(FileInputStream.java:147) at org.apache.commons.io.FileUtils.openInputStream(FileUtils.java:139) at org.apache.commons.io.FileUtils.lineIterator(FileUtils.java:1210) at org.apache.commons.io.FileUtils.lineIterator(FileUtils.java:1231) at hudson.plugins.git.GitChangeLogParser.parse(GitChangeLogParser.java:45) at hudson.plugins.git.GitChangeLogParser.parse(GitChangeLogParser.java:26) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:899) at hudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:873) 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-19994) Unable to delete workspace
Mark Waite resolved JENKINS-19994 as Fixed Unable to delete workspace git client plugin 1.6.1 or git client plugin 1.7.0 (which ever is chosen as the next release version number of the git client plugin) should resolve some of the cases where this problem happens. There are likely still other cases which are not yet fixed (like the case documented in JENKINS-20585). Change By: Mark Waite (05/Jan/14 12:04 PM) Status: InProgress 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] [git] (JENKINS-19994) Unable to delete workspace
Mark Waite reopened JENKINS-19994 Unable to delete workspace A new release of the git plugin will also be required before this bug is fixed. There is at least one call in the git plugin which needs to use the ChangelogCommand.abort() method that was added after git client plugin 1.6.0 was released. The git plugin version will need to be newer than 2.0 before this bug fix will be visible, assuming the pull request for the change is accepted. Change By: Mark Waite (06/Jan/14 1:24 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-19994) Unable to delete workspace
Mark Waite resolved JENKINS-19994 as Fixed Unable to delete workspace Git plugin pull request has been accepted for a Git plugin version after 2.0. Not yet clear what version number that will be, only that the change is not in version 2.0, so it should be in the next version released after 2.0. Change By: Mark Waite (06/Jan/14 1:45 PM) Status: Reopened 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] [git-client] (JENKINS-21275) hudson.plugins.git.GitException: Error performing git command ... Caused by: java.lang.NoSuchFieldError: MINUTES
Mark Waite commented on JENKINS-21275 hudson.plugins.git.GitException: Error performing git command ... Caused by: java.lang.NoSuchFieldError: MINUTES I recommend this not be fixed. https://wiki.jenkins-ci.org/display/JENKINS/Java+5+Compatibility states that as of Jenkins 1.520, Java 6 or later is required at runtime. Fixing this now will still only give the person who reported the bug a limited time before they will be unable to use Java 5. Strictly speaking, the git-client-plugin pom.xml declares that git-client-plugin needs Jenkins 1.480 as its minimum version, so there is a reasonable argument that git-client should support Java 5. It does not (as noted by this bug report). Modifying it to support Java 5 seems like wasted effort because the rest of the infrastructure does not support Java 5 as of Jenkins 1.520. I'm not the maintainer of the plugin, just an interested person, but I think that the maintainer has plenty of things to do on the plugin without attempting to make it compatible with a Java 5 runtime. 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-client] (JENKINS-21275) hudson.plugins.git.GitException: Error performing git command ... Caused by: java.lang.NoSuchFieldError: MINUTES
Mark Waite closed JENKINS-21275 as Wont Fix hudson.plugins.git.GitException: Error performing git command ... Caused by: java.lang.NoSuchFieldError: MINUTES No further work needed on this bug. Won't be fixed. Change By: Mark Waite (08/Jan/14 2:57 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 -- 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-client] (JENKINS-21275) hudson.plugins.git.GitException: Error performing git command ... Caused by: java.lang.NoSuchFieldError: MINUTES
Mark Waite resolved JENKINS-21275 as Wont Fix hudson.plugins.git.GitException: Error performing git command ... Caused by: java.lang.NoSuchFieldError: MINUTES I confirmed with Nicolas De Loof that this bug won't be fixed. It is a valid bug report for users of Jenkins 1.480 through 1.519, but is not worth the effort to fix when the rest of the Jenkins community has already accepted the requirement for a Java 6 runtime. Change By: Mark Waite (08/Jan/14 2:57 PM) Status: Open Resolved Resolution: WontFix 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-17681) LastSuccessful and LastStable symlinks are invalid under Windows
Mark Waite edited a comment on JENKINS-17681 LastSuccessful and LastStable symlinks are invalid under Windows This problem is also visible in Jenkins 1.509.1 LTS release candidate. It appears as a stack trace WARNING: Failed to update hudson.model.FreeStyleProject@1b7e8eff[jenkins-demo] l astSuccessfulBuild permalink for jenkins-demo #24 java.nio.file.NoSuchFileException: C:\Users\Mark\.jenkins\jobs\jenkins-demo\builds\lastSuccessfulBuild.tmp at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) at sun.nio.fs.WindowsLinkSupport.readLink(WindowsLinkSupport.java:56) at sun.nio.fs.WindowsFileSystemProvider.readSymbolicLink(WindowsFileSystemProvider.java:636) at java.nio.file.Files.readSymbolicLink(Files.java:1382) at sun.reflect.GeneratedMethodAccessor125.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at hudson.Util.resolveSymlink(Util.java:1188) at jenkins.model.PeepholePermalink.updateCache(PeepholePermalink.java:146) at jenkins.model.PeepholePermalink.resolve(PeepholePermalink.java:118) at hudson.model.Job.getLastSuccessfulBuild(Job.java:802) at sun.reflect.GeneratedMethodAccessor213.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:677) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:770) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:677) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:770) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:583) at org.kohsuke.stapler.Stapler.service(Stapler.java:214) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:227) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150) at
