-
New Feature
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins ver. 1.625.2
Git Plugin 2.4.1
Gerrit repository on the origin side with SSH authentification
Reproduction:
- Take a working job with Git SCM Polling enabled (with the fast / "ls-remote" method)
- Provoke an error in the origin response (e.g. see Log below)
- Git Polling ends with "No changes"
The Job stays at "blue" (successful) although the Polling clearly had errors --> the not working job might stay undiscovered quite long
Git Polling Log:
Started on Jan 31, 2016 10:00:00 PM Using strategy: Default [poll] Last Built Revision: Revision 1231223345345345345345345345345345345543 (refs/remotes/origin/master) using GIT_SSH to set credentials SSH Key for someUser > git --version # timeout=10 > git -c core.askpass=true ls-remote -h ssh://someUser@localhost/example-projects/example1 # timeout=10 FATAL: hudson.plugins.git.GitException: Command "git -c core.askpass=true ls-remote -h ssh://someUser@localhost/example-projects/example1" returned status code 128: stdout: stderr: fatal: Project not found: example-projects/example1 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. hudson.util.IOException2: hudson.plugins.git.GitException: Command "git -c core.askpass=true ls-remote -h ssh://someUser@localhost/example-projects/example1" returned status code 128: stdout: stderr: fatal: Project not found: example-projects/example1 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:529) at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:381) at hudson.scm.SCM.poll(SCM.java:398) at hudson.model.AbstractProject._poll(AbstractProject.java:1452) at hudson.model.AbstractProject.poll(AbstractProject.java:1355) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:510) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:539) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true ls-remote -h ssh://someUser@localhost/example-projects/example1" returned status code 128: stdout: stderr: fatal: Project not found: example-projects/example1 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1441) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1335) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1326) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getHeadRev(CliGitAPIImpl.java:2435) at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:583) at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:527) ... 12 more Done. Took 0.42 sec No changes
I'm not sure there is currently any location to show that git polling failed. The results of the individual jobs are not dependent on a polling failure, so showing the most recent job as a failure due to a polling failure seems like the wrong choice.
Would it be helpful if the git polling log line in the job page were changed somehow to show that polling failed? For example, if the red text "(failed)" were appended to the line which currently says "Git polling log"?
Alternately, would it help if the polling log icon were changed from the current clipboard icon to a clipboard behind a "red slashed circle"?
I'm not ready to implement either of those ideas yet, but I can see how they would help me when I'm testing the plugin, since I could more easily see which jobs had a polling failure, instead of requiring that I visit each job and open each git polling log.