-
Bug
-
Resolution: Fixed
-
Major
-
OS: Debian (squeeze, updated today)
jenkins: 1.500 (installed .deb from http://pkg.jenkins-ci.org/debian/ binary/ Packages)
git plugin: 1.1.26 (installed from jenkins web interface), did not work with 1.1.22 neither
git version 1.7.2.5 (from Debian)
I have set-up a build with the git plugin - it uses polling, but it always fails with the following error seen in "Git Polling Log":
Git Polling Log
Started on Feb 10, 2013 12:06:00 PM
Using strategy: Default
[poll] Last Build : #2
Fetching changes from the remote Git repositories
Fetching upstream changes from git://devel.brailcom.org/git/lcg.git
Polling for changes in
Seen branch in repository origin/HEAD
Seen branch in repository origin/eurochance
Seen branch in repository origin/master
Seen branch in repository origin/parse-inline-markup
ERROR: Failed to record SCM polling for hudson.model.FreeStyleProject@6099210f[LCG]
java.lang.RuntimeException: No author in changeset null
at hudson.plugins.git.GitChangeSet.getAuthorName(GitChangeSet.java:324)
at hudson.plugins.git.GitSCM.isRevExcluded(GitSCM.java:1788)
at hudson.plugins.git.GitSCM.access$300(GitSCM.java:72)
at hudson.plugins.git.GitSCM$1.invoke(GitSCM.java:755)
at hudson.plugins.git.GitSCM$1.invoke(GitSCM.java:731)
at hudson.FilePath.act(FilePath.java:865)
at hudson.FilePath.act(FilePath.java:838)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:731)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:644)
at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
at hudson.scm.SCM.poll(SCM.java:373)
at hudson.model.AbstractProject._poll(AbstractProject.java:1480)
at hudson.model.AbstractProject.poll(AbstractProject.java:1410)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:439)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:468)
at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
- is duplicated by
-
-
- Resolved
-
[JENKINS-16737] java.lang.RuntimeException: No author in changeset null
I agree that wiping the workspace is just a temporary fix. Unfortunately no one (including me) has been able to provide a set of steps which will consistently show the problem. Without a set of steps to consistently show the problem, I have no reasonable way to decide if the bug is fixed.
My "thought experiment" to prevent a more serious problem (fail the build) when a minor problem happens (cannot compute the author of one of the changes) was to return an author that is wrong (like "Unknown Author <unknown@bad.example.com>" rather than throwing a RuntimeException. Is it better to fail the build with a RuntimeException when the author of a change cannot be computed, or is it better to return an author that is wrong but does not fail the build?
Is an accurate author for each change more important than a passing build?
Roi Rosenthal
added a comment - wiping the workspace worked as a short term temporary solution for us as well, the problem quickly resurfaced.
upgrading the slave.jar to be aligned with jenkins version (current working version - jenkins 1.554.3, git client plugin 1.8.0
, git plugin 2.2.2) solved all our issues.
@Mark Waite
IMHO The priority should remain high or switch to critical as environments with many jobs & slaves are very hard to maintain when the problem surfaces.
the workaround you suggested is viable
Roi Rosenthal
added a comment - wiping the workspace worked as a short term temporary solution for us as well, the problem quickly resurfaced.
upgrading the slave.jar to be aligned with jenkins version (current working version - jenkins 1.554.3, git client plugin 1.8.0
, git plugin 2.2.2) solved all our issues.
@Mark Waite
IMHO The priority should remain high or switch to critical as environments with many jobs & slaves are very hard to maintain when the problem surfaces.
the workaround you suggested is viable 
Steve Kerxhalli
added a comment - FWIW. I have a Jenkins server running on Linux (2.6.43.8-1.fc15.x86_64) and a Jenkins server running on Windows (Server 2008 R2). Both are running Jenkins v1.554.3
I have a slave of the Linux server running on Windows 7.
I have a slave of the Windows server also running on Windows 7. Both of the slaves are VMs and one is a clone of the other.
I have the same, Git based, build running on both of the slaves. Both use local (vs. Network) disk for their repositories.
Both slaves perform Git operations on the slave (vs. the server, since the server does not have Git installed).
In other words, I have two distinct Jenkins environments where the only difference between the two is that one uses a Linux Jenkins server and the other users a Windows Jenkins server.
This issue, "No author in changeset" only occurs in the environment with the Windows server.
I'm willing to try a more recent LTS release and/or upgrade the slaves if that would be of any help.
Steve Kerxhalli
added a comment - FWIW. I have a Jenkins server running on Linux (2.6.43.8-1.fc15.x86_64) and a Jenkins server running on Windows (Server 2008 R2). Both are running Jenkins v1.554.3
I have a slave of the Linux server running on Windows 7.
I have a slave of the Windows server also running on Windows 7. Both of the slaves are VMs and one is a clone of the other.
I have the same, Git based, build running on both of the slaves. Both use local (vs. Network) disk for their repositories.
Both slaves perform Git operations on the slave (vs. the server, since the server does not have Git installed).
In other words, I have two distinct Jenkins environments where the only difference between the two is that one uses a Linux Jenkins server and the other users a Windows Jenkins server.
This issue, "No author in changeset" only occurs in the environment with the Windows server.
I'm willing to try a more recent LTS release and/or upgrade the slaves if that would be of any help.
Steve Kerxhalli
added a comment - Oh, and I didn't mention, both servers have Git Client Plugin v1.9.1 and Git Plugin v2.2.2
Steve Kerxhalli
added a comment - Oh, and I didn't mention, both servers have Git Client Plugin v1.9.1 and Git Plugin v2.2.2 Code changed in jenkins
User: Mark Waite
Path:
src/main/java/hudson/plugins/git/GitChangeSet.java
src/test/java/hudson/plugins/git/GitChangeSetEmptyTest.java
src/test/java/hudson/plugins/git/GitChangeSetEuroTest.java
src/test/java/hudson/plugins/git/GitChangeSetSimpleTest.java
src/test/java/hudson/plugins/git/GitChangeSetTest.java
http://jenkins-ci.org/commit/git-plugin/287e5434d790c9a1c7204e38a09cb843b209a3d7
Log:
[Fix JENKINS-16737] and [Fix JENKINS-10434] - no exception if author not found
Return unknown user rather than throwing exception in GitChangeSet
Refer to JENKINS-16737 and JENKINS-10434 for two cases where a
GitChangeSet cannot find an author and throws a RuntimeException when
it would be much better to report an unknown user and allow execution
to continue.
Added a Polish character to the accented character test
Use more diacritics in the latin accented character test
Use parameterized GitChangeSet test to better cover cases
Code changed in jenkins
User: Mark Waite
Path:
src/main/java/hudson/plugins/git/GitChangeSet.java
src/test/java/hudson/plugins/git/GitChangeSetEmptyTest.java
src/test/java/hudson/plugins/git/GitChangeSetEuroTest.java
src/test/java/hudson/plugins/git/GitChangeSetSimpleTest.java
src/test/java/hudson/plugins/git/GitChangeSetTest.java
http://jenkins-ci.org/commit/git-plugin/cb6f13a3e3158332f76a45e853b3766fe83d5828
Log:
[Fix JENKINS-16737] and [Fix JENKINS-10434] - no exception if author not found
Return unknown user rather than throwing exception in GitChangeSet
Refer to JENKINS-16737 and JENKINS-10434 for two cases where a
GitChangeSet cannot find an author and throws a RuntimeException when
it would be much better to report an unknown user and allow execution
to continue.
Added a Polish character to the accented character test
Use more diacritics in the latin accented character test
Use parameterized GitChangeSet test to better cover cases
Fix should be in git plugin 2.2.8, preventing the plugin from throwing an exception even if it finds a case where the changeset author is null. It will return an unknown user rather than throwing an exception.
Unfortunately, because I can't duplicate the problem, I can't be 100% confident that will resolve the problem entirely, but I am reasonably confident that getAuthorName will no longer throw a RuntimeException.
According to JENKINS-25132, ci.jenkins-ci.org has that problem. So it may be possible to determine whether the fix works by upgrading Git plugin there.
Hi Mark,
Wiping workspace is just temporary fix, again and again facing this issue from longtime, used option "commit author in changelog" also not fixed issue.
Regards,
Sankar Bheema.