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

Git creates malformed changelog.xml files

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-client-plugin
    • Labels:
      None
    • Environment:
      jenkins 1.608
      git-plugin 2.3.5
      git-client 1.17.0
      git 1.9.2/FreeBSD 9.1 on master or git 2.3.1/FreeBSD10.1 on slaves
    • Similar Issues:

      Description

      While investigating JENKINS-28920 it became apparent that some git component was creating malformed changelog.xml files. These headers are missing SHA1 values for the parent value.

      I don't know why the headers were missing, any information about where the changelog.xml is generated would be helpful, since a git log --pretty=raw $SHA1 in the slave working directory shows the parent correctly. (I should note that the master is an older git because maintenance is downtime and the slaves are all ansible'ized and up to date.)

      We are also using reference repositories which are updated nightly.

      The log from the build that started this issue looks like this:

      00:00:00.013 Started by user J. Longman
      00:00:00.014 Started by user J. Longman
      00:00:00.032 Building remotely on vagrant-freebsd-10-10.10.1.174 (special swarm) in workspace /usr/home/jenkins/workspace/4.9.1
      00:00:00.033 
      00:00:00.033 Deleting project workspace... done
      00:00:00.197 
      00:00:01.042  > /usr/local/bin/git rev-parse --is-inside-work-tree # timeout=10
      00:00:01.440 Fetching changes from the remote Git repository
      00:00:01.443  > /usr/local/bin/git config remote.origin.url ssh://jenkins@git/git/Main.git # timeout=10
      00:00:01.475 Fetching upstream changes from ssh://jenkins@git/git/Main.git
      00:00:01.477  > /usr/local/bin/git --version # timeout=10
      00:00:01.501  > /usr/local/bin/git -c core.askpass=true fetch --tags --progress ssh://jenkins@git/git/Main.git +refs/heads/*:refs/remotes/origin/* # timeout=15
      00:00:02.357  > /usr/local/bin/git rev-parse refs/remotes/origin/Special_9^{commit} # timeout=10
      00:00:02.370  > /usr/local/bin/git rev-parse refs/remotes/origin/origin/Special_9^{commit} # timeout=10
      00:00:02.381 Checking out Revision f316cb2ceee9a38b393629c49eba2d33dc9669f6 (refs/remotes/origin/Special_9)
      00:00:02.393  > /usr/local/bin/git config core.sparsecheckout # timeout=10
      00:00:02.409  > /usr/local/bin/git checkout -f f316cb2ceee9a38b393629c49eba2d33dc9669f6 # timeout=15
      00:00:04.336  > /usr/local/bin/git rev-list 477e7dfabbfe71fd12d12b4238cc3d105061310c # timeout=10
      00:00:09.567 FATAL: null
      00:00:09.567 java.lang.ArrayIndexOutOfBoundsException
      00:00:09.597 FATAL: null
      00:00:09.597 java.lang.ArrayIndexOutOfBoundsException
      00:00:09.611 Finished: FAILURE
      

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment - - edited

            This looks like it may be related to JENKINS-28134 , which was introduced with git client plugin 1.17.0. If you revert to git client plugin 1.16.1 then the problem may be resolved until such time as a new version of the git plugin is available to fix it.

            Does reverting to git client plugin 1.16.1 work around the problem?

            However, since your console log does not include a stack trace, and your bug report does not refer to the plugin version numbers you're using, it is possible (even likely) that this is unrelated to JENKINS-28134.

            Show
            markewaite Mark Waite added a comment - - edited This looks like it may be related to JENKINS-28134 , which was introduced with git client plugin 1.17.0. If you revert to git client plugin 1.16.1 then the problem may be resolved until such time as a new version of the git plugin is available to fix it. Does reverting to git client plugin 1.16.1 work around the problem? However, since your console log does not include a stack trace, and your bug report does not refer to the plugin version numbers you're using, it is possible (even likely) that this is unrelated to JENKINS-28134 .
            Hide
            jlongman jlongman added a comment -

            Sorry, I forgot to copy them when I continued from JENKINS-28290, which I mislabeled with CORE, a common label we use with jira - they are now updated and I am indeed running git-client 1.17.0.
            However, I should note that stacktrace does not appear anywhere, but I will indeed try reverting the git-client

            Show
            jlongman jlongman added a comment - Sorry, I forgot to copy them when I continued from JENKINS-28290 , which I mislabeled with CORE, a common label we use with jira - they are now updated and I am indeed running git-client 1.17.0. However, I should note that stacktrace does not appear anywhere, but I will indeed try reverting the git-client
            Hide
            jlongman jlongman added a comment -

            At first blush it appears 1.16.1 does not re-create the issue. To be explicit I am running git-plugin 2.3.5 and git-client 1.16.1.

            Have you considered withdrawing 1.17.0 until there is a reliable fix?

            Show
            jlongman jlongman added a comment - At first blush it appears 1.16.1 does not re-create the issue. To be explicit I am running git-plugin 2.3.5 and git-client 1.16.1. Have you considered withdrawing 1.17.0 until there is a reliable fix?
            Hide
            markewaite Mark Waite added a comment -

            I'm not aware of any reasonable way to withdraw a plugin. We're actively working to release the next version of the git plugin which includes the fix for the git plugin bug that was exposed by the change in git client plugin 1.17.0. I'd rather "press forward" with the release processes that I know work, rather than trying to find a way to use a "withdraw" process that I've never used before.

            Show
            markewaite Mark Waite added a comment - I'm not aware of any reasonable way to withdraw a plugin. We're actively working to release the next version of the git plugin which includes the fix for the git plugin bug that was exposed by the change in git client plugin 1.17.0. I'd rather "press forward" with the release processes that I know work, rather than trying to find a way to use a "withdraw" process that I've never used before.
            Hide
            jlongman jlongman added a comment -

            Sure, then if the lead-up to the next release is long, and if I may, another suggestion: just release the 1.16.1 code as 1.17.1. It's not ideal but at least prevents exposing a blocker that completely prevents builds and generates duplicate Jira's etc.

            (I'm not sure how something which completely breaks builds is a Minor - was that auto-assigned by the system? I may have forgotten to change it, and I'd rather not now that it has developer attention).

            Show
            jlongman jlongman added a comment - Sure, then if the lead-up to the next release is long, and if I may, another suggestion: just release the 1.16.1 code as 1.17.1. It's not ideal but at least prevents exposing a blocker that completely prevents builds and generates duplicate Jira's etc. (I'm not sure how something which completely breaks builds is a Minor - was that auto-assigned by the system? I may have forgotten to change it, and I'd rather not now that it has developer attention).
            Hide
            markewaite Mark Waite added a comment -

            The original submitter marked that as minor because the work around (downgrade from 1.17.0 to 1.16.1) is straightforward. If we can't release a fixed version of the git plugin quickly then we will need to use your suggestion and create a 1.17.1 which only a version increment of 1.16.1.

            Show
            markewaite Mark Waite added a comment - The original submitter marked that as minor because the work around (downgrade from 1.17.0 to 1.16.1) is straightforward. If we can't release a fixed version of the git plugin quickly then we will need to use your suggestion and create a 1.17.1 which only a version increment of 1.16.1.
            Hide
            markewaite Mark Waite added a comment -

            The git client plugin 1.17.1 released 8 May 2015 using the code from git client plugin 1.16.1. That hides the git plugin bug which caused this bug and others.

            Once a simultaneous release of git plugin (master branch) and git client plugin (master branch) can be confirmed that they are reliable, this bug will be resolved. Until then, it is hidden from view, but not resolved.

            Show
            markewaite Mark Waite added a comment - The git client plugin 1.17.1 released 8 May 2015 using the code from git client plugin 1.16.1. That hides the git plugin bug which caused this bug and others. Once a simultaneous release of git plugin (master branch) and git client plugin (master branch) can be confirmed that they are reliable, this bug will be resolved. Until then, it is hidden from view, but not resolved.
            Hide
            markewaite Mark Waite added a comment -

            Fix included in git plugin 2.4.0 released 18 July 2015

            Show
            markewaite Mark Waite added a comment - Fix included in git plugin 2.4.0 released 18 July 2015

              People

              • Assignee:
                ndeloof Nicolas De Loof
                Reporter:
                jlongman jlongman
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: