Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-16737

java.lang.RuntimeException: No author in changeset null

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
    • Environment:
    • Similar Issues:

      Description

      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)

        Attachments

          Issue Links

            Activity

            dusek Boris Dušek created issue -
            Hide
            gbougeard Greg BOUGEARD added a comment -

            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.

            Show
            gbougeard Greg BOUGEARD added a comment - 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.
            Hide
            ndeloof Nicolas De Loof added a comment -

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

            Show
            ndeloof Nicolas De Loof added a comment - raw log parsing is fragile, I'd like to rely on --format to make it more predictible
            Hide
            gbougeard Greg BOUGEARD added a comment -

            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 "

            {\"sha\":\"$sha\",\"message\":\"$message\",\"author\":\"$author\",\"commit\":\"$commit\",\"date\":\"$date\"}

            ,"
            }

            #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

            Show
            gbougeard Greg BOUGEARD added a comment - 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 " {\"sha\":\"$sha\",\"message\":\"$message\",\"author\":\"$author\",\"commit\":\"$commit\",\"date\":\"$date\"} ," } #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
            Hide
            maxvohlken Max Vohlken added a comment -

            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.

            Show
            maxvohlken Max Vohlken added a comment - 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.
            Hide
            sankarbheema sankar bheema added a comment - - edited

            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

            Show
            sankarbheema sankar bheema added a comment - - edited 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
            sankarbheema sankar bheema made changes -
            Field Original Value New Value
            Assignee Nicolas De Loof [ ndeloof ] Max Vohlken [ maxvohlken ]
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            Hide
            sguth Shaun Guth added a comment -

            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()))

            { changelog.excludes(lastRevWas.getSHA1()); exclusion = true; }
            Show
            sguth Shaun Guth added a comment - 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())) { changelog.excludes(lastRevWas.getSHA1()); exclusion = true; }
            Hide
            tetra Thomas Carsuzan added a comment -

            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 ?

            Show
            tetra Thomas Carsuzan added a comment - 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 ?
            Hide
            tetra Thomas Carsuzan added a comment -

            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

            Show
            tetra Thomas Carsuzan added a comment - 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
            Hide
            hbrev Heiko Briebrecher added a comment -

            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.

            Show
            hbrev Heiko Briebrecher added a comment - 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.
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            Hide
            madsnielsen Mads Nielsen added a comment -

            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

            Show
            madsnielsen Mads Nielsen added a comment - 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
            Hide
            abergmeier Andreas Bergmeier added a comment -

            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?

            Show
            abergmeier Andreas Bergmeier added a comment - 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?
            Hide
            markewaite Mark Waite added a comment -

            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?

            Show
            markewaite Mark Waite added a comment - 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?
            Hide
            sankarbheema sankar bheema added a comment -

            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.

            Show
            sankarbheema sankar bheema added a comment - 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.
            Hide
            markewaite Mark Waite added a comment -

            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?

            Show
            markewaite Mark Waite added a comment - 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?
            Hide
            roiros 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

            Show
            roiros 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
            Hide
            skerxhalli 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.

            Show
            skerxhalli 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.
            Hide
            skerxhalli 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

            Show
            skerxhalli 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
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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
            Hide
            markewaite Mark Waite added a comment -

            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.

            Show
            markewaite Mark Waite added a comment - 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.
            markewaite Mark Waite made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            danielbeck Daniel Beck added a comment -

            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.

            Show
            danielbeck Daniel Beck added a comment - 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.
            danielbeck Daniel Beck made changes -
            Link This issue is duplicated by JENKINS-25132 [ JENKINS-25132 ]
            Hide
            markewaite Mark Waite added a comment -

            Fix released in git plugin 2.3 10 Nov 2014

            Show
            markewaite Mark Waite added a comment - Fix released in git plugin 2.3 10 Nov 2014
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 147562 ] JNJira + In-Review [ 206393 ]

              People

              • Assignee:
                maxvohlken Max Vohlken
                Reporter:
                dusek Boris Dušek
              • Votes:
                11 Vote for this issue
                Watchers:
                24 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: