Hi,

I'm getting a quite similar error :

08/01/2014 10:00:27 Archiving artifacts
08/01/2014 10:00:27 FATAL: No author in changeset 506fc54deb5c89c43450dc60a054159999198b0atree
08/01/2014 10:00:27 java.lang.RuntimeException: No author in changeset 506fc54deb5c89c43450dc60a054159999198b0atree
08/01/2014 10:00:27 at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:336)
08/01/2014 10:00:27 at hudson.model.AbstractBuild.getCulprits(AbstractBuild.java:414)
08/01/2014 10:00:27 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:710)
08/01/2014 10:00:27 at hudson.model.Run.execute(Run.java:1702)
08/01/2014 10:00:27 at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:519)
08/01/2014 10:00:27 at hudson.model.ResourceController.execute(ResourceController.java:88)
08/01/2014 10:00:27 at hudson.model.Executor.run(Executor.java:231)

I have checked the git-plugin code and I think the id of the commit is not well retrieved.
506fc54deb5c89c43450dc60a054159999198b0a is a valid SHA1 but the id retrieved is 506fc54deb5c89c43450dc60a054159999198b0atree , so the tree suffix is too much.
The issue might be in the parseCommit method or maybe it can be linked to a specific git version (like the issue of maven release plugin with git 1.8.5).

I'm using :
git 1.7.9.5.
Jenkins GIT client plugin 1.6.0
Jenkins GIT plugin 2.0

I'm not sure about the scenario to reproduce this error but there is the git log of the commit :

commit 506fc54deb5c89c43450dc60a054159999198b0a
Author: JENKINS <jenkins@xxx.com>
Date: Wed Jan 8 01:13:06 2014 +0100

release Langs

Change-Id: I157faff2efffdb369933958dfb15842f0e9c4ff7

commit f25811f05aeb812bdf4a1c2c50d251f0e088f9f5
Author: JENKINS <jenkins@xxx.com>
Date: Fri Jan 3 01:12:26 2014 +0100

release Langs

Change-Id: I82be648aaa25dcbc81c2ace3ac2dea91eba6d425

commit 3be79c86892135e7f0d4a40642cd2710cd7013c2
Author: JENKINS <jenkins@xxx.com>
Date: Fri Dec 27 01:13:28 2013 +0100

release Langs

Change-Id: I42fbc4d166161d467602f7b3c6ef6621c9512545

I don't have a Jenkins Plug-in dev ready environment so I can't go further right now.
I hope the details I gave could help.

raw log parsing is fragile, I'd like to rely on --format to make it more predictible

I'm using a gitjs shell script like this :

#!/bin/sh
TAG_START=$1
TAG_END=$2

function escape_chars {
sed -r -e 's/(["\\])/\\\1/g' -e 's/\t/ /g'
}
function format {
sha=$(git log -n1 --pretty=format:%h $1 | escape_chars)
message=$(git log -n1 --pretty=format:%s $1 | escape_chars)
author=$(git log -n1 --pretty=format:'%aN' $1 | escape_chars)
commit=$(git log -n1 --pretty=format:%H $1 | escape_chars)
date=$(git log -n1 --pretty=format:%ai $1 | escape_chars)
echo "

,"
}

#echo "git log ${TAG_START}..${TAG_END}"

for hash in $(git rev-list ${TAG_START}..${TAG_END})
do
format $hash
done

maybe it can inspire you

I found the cause for the errors:

08/01/2014 10:00:27 Archiving artifacts
08/01/2014 10:00:27 FATAL: No author in changeset 506fc54deb5c89c43450dc60a054159999198b0atree
08/01/2014 10:00:27 java.lang.RuntimeException: No author in changeset 506fc54deb5c89c43450dc60a054159999198b0atree
08/01/2014 10:00:27 at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:336)

This is caused by a change in the Multiple SCMs Plugin that changed the format of the changelog.xml that it creates. The Git Plugin is parsing the chagelog.xml as a normal text file and not as an XML file. The Multiple SCMs Plugin version 0.3 started to HTML escape the "<>" around the email address of the author and committer in the git change log which broke the parser in the Git Plugin.

For example in a failing changelog.xml
with the 0.3 Multiple SCMs Plugin we have:
<multi-scm-log>
<sub-log scm="hudson.plugins.git.GitSCM">
<![CDATA[commit 67be86f982e16ef56a6efaede836f0e9619c95f1
tree fb60b7ae44641004d799d0a6d2d38f377ea59d55
parent d1ff9a84aaaed6d2e6ab6116b887ab80dc959120
author myuser <myuser@mydomain.com> 1398272644 -0400

Since the <> are being escaped the Git Plugin parser is not able to find the author.

With the old plugin the "<>" weren't escaped:

<multi-scm-log>
<sub-log scm="hudson.plugins.git.GitSCM">
<![CDATA[commit 67be86f982e16ef56a6efaede836f0e9619c95f1
tree fb60b7ae44641004d799d0a6d2d38f377ea59d55
parent d1ff9a84aaaed6d2e6ab6116b887ab80dc959120
author myuser <myuser@mydomain.com> 1398272644 -0400

Since the changelog.xml is an XML formatted file shouldn't the parser in the Git Plugin use an XML parser to retrieve the contents of the <sub-log> tag.

So reverting back to the 0.2 Multiple SCMs Plugin fixed this for me.

Hi Max,

Same issue i am facing on our builds, after downgrading MULTISCM plugin to 0.2 also, This is affecting only on windows slave. To avoid this situation currently i am wiping out workspace, but it is giving temporary fix only after 5 to 6 builds again the same situation is repeating. Unable to find which plugin causing this. Checked jenkins changes option(changes from git) on that build which failed, it is able to show commit <id> by , unable to show author name.

Changes from git summary: Commit 5f268778c4701c4b8a6573a6d00297349834882e by

Jenkins console output:
-----------------------
02:03:35 Archiving artifacts
02:03:38 FATAL: No author in changeset 5f268778c4701c4b8a6573a6d00297349834882e
02:03:38 java.lang.RuntimeException: No author in changeset 5f268778c4701c4b8a6573a6d00297349834882e
02:03:38 at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:336)
02:03:38 at hudson.model.AbstractBuild.getCulprits(AbstractBuild.java:352)
02:03:38 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:667)
02:03:38 at hudson.model.Run.execute(Run.java:1714)
02:03:38 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
02:03:38 at hudson.model.ResourceController.execute(ResourceController.java:88)
02:03:38 at hudson.model.Executor.run(Executor.java:231)

can you help me is there any other area which is creating this issue?

My Environment:
---------------
Jenkins Version: 1.558
Git Plugin Version: 2.0
Git Client Plugin: 1.4.5
Multiple SCMs Plugin: 0.2
Operating system: windows

You could try toggling the value of the git plugin additional behavior "Use commit author in changelog" to see if that reduces the frequency of the issue.

I've seen instances where the git plugin incorrectly throws the "No author in changeset" exception, even without the MultiSCM plugin. I haven't found specific conditions which cause it repeatably, but have definitely seen it, and have seen that after a build or two, the problem seems to "hide itself" again.

I think it is a bug in the git plugin that it should not throw a RuntimeException when an author cannot be extracted from a changeset. I don't think the author is critical enough to the operation of the plugin to justify failing a build if the parsing fails.

I'm seeing similar behavior to Sankar. Clearing the workspace seems to fix things temporarily, but eventually it returns.

I don't have a solid repro, but this might have to do with the logic in GitSCM.java that excludes some changelog data in computeChangeLog()

Build lastRevWas = getBuildChooser().prevBuildForChangelog(b.getName(), previousBuildData, git, context);
if (lastRevWas != null && git.isCommitInRepo(lastRevWas.getSHA1()))

I confirm that this still happens randomly with :
Jenkins 1.569
Git 2.2.2
Git client 1.9.1

When I check the changelog.xml file produced on the disk, it seems ok. It will be great if I could debug it when it happens but it is very hard to catch.
What about removing the exception and adding an error log instead while it is being fixed ?

Ok, I could finally debug it.
The problem comes from the lines passed to GitChangeSet.parseCommit(List<String> lines)
I got only these :

commit 51ffaaa7d9cd227d6a3a1da44118306276ab1af6
tree bea0dd38c05f1d22c9b7fe4cc430a052beb68

So neither author nor commiter.
I will try to understand why and what can be the solution.

Thomas

I could sidestep the error by updating the slave.jar on our jenkins slave to the latest version.
AFAIK changesets are determined on the slave and then sent to the jenkins master. Occasionally they got truncated at an arbitrary position.

The truncated changelog entries are stored in $JENKINS_HOME/jobs/XXX/builds/NNN/changelog.xml and need to be deleted/corrected to prevent further RuntimeExceptions while building or browsing the job history.

That is an interesting combination of observations. Since the problem is intermittent (at least for me), and does not always happen on the same machine, I'm not sure how I would confidently assure that the updating slave.jar was the solution.

I will certainly investigate my machines to confirm they are all running the current slave.jar.

When I've seen the problem, I was usually able to resolve it by wiping the workspace. A workspace wipe does not touch the changelog.xml file, so I'm a little suspicious that the changelog.xml is not the problem.

I'm seeing this as well, it's intermittent, and sometimes wiping workspace resolves your issue...not always.

Git plugin version 2.2.2 and Jenkins 1.554.2

Same problem here. Kind of surprised that this has a Major prio since more than a year. Is there any way to analyze this or help otherwise?

I think the priority is wrong. The work around of wiping the workspace is relatively straightforward and has resolved the issue in all the cases where I've encountered it. I've never had to take the second work around of removing the changelog.xml file. Updating the slave.jar file did not seem to alter the seemingly random nature of the problem.

I've considered that it might be better for users if the getAuthorName() method were modified to never throw an exception, but always return something. If the author name cannot be determined, then return something like "Unknown Author <unknown@bad.example.com>".

Would that be enough better than the current state to be worth the effort to make the change?

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.

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?

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

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.

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.

Fix released in git plugin 2.3 10 Nov 2014