• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • None
    • CentOS release 6.7 (Final)
      Java 1.7.0_85
      Jenkins 1.624 installed via RPM
      Git Plugin 2.4.0
      Git client plugin 1.18.0

      The commit messages in the changes view began to be truncated at some recent version of the Git plugin.

      This problem can be seen in Problem1.png where the commit messages are truncated. In Problem2.png you can see that the full message is available but it appears that there is a newline in there. Correct.png is a screenshot of an older version (not entirely sure which, it's from Apache's Jenkins server) where the same commit is correctly displayed.

      This does not only affect display but also the E-Mail notifications that are sent making them relatively useless.

      There is - as far as I know - no workaround hence I marked it as major and not as minor.

        1. Correct.png
          Correct.png
          82 kB
        2. Problem1.png
          Problem1.png
          618 kB
        3. Problem2.png
          Problem2.png
          46 kB

          [JENKINS-29977] Git Plugin truncates changelog

          Mark Waite added a comment -

          The `mvn clean install` ran to completion for me in that environment. I even removed the ~/.m2 directory completely and ran it again just to be sure. My Windows machines have all been "touched" by my development work, so I'm not sure any of them can be cleaned enough to duplicate your setup.

          You may need to move the ~/.m2 directory temporarily to another location as an alternate test.

          Mark Waite added a comment - The `mvn clean install` ran to completion for me in that environment. I even removed the ~/.m2 directory completely and ran it again just to be sure. My Windows machines have all been "touched" by my development work, so I'm not sure any of them can be cleaned enough to duplicate your setup. You may need to move the ~/.m2 directory temporarily to another location as an alternate test.

          Chris Kloehn added a comment -

          I will do that, as well as spin up a linux environment to try and match your set up. If all this fails though I don't have a way to run any manual tests, unless you know of any other ways to load my version of the plugin into Jenkins. 

          Chris Kloehn added a comment - I will do that, as well as spin up a linux environment to try and match your set up. If all this fails though I don't have a way to run any manual tests, unless you know of any other ways to load my version of the plugin into Jenkins. 

          Andrew Macks added a comment - - edited

          So, after tracking this issue for a while, and getting excited over the last couple of days with Chris' involvement, I got a little concerned when the issue became Unassigned again and decided to dig into it myself.

          It turns out that the issue is actually in git-client-plugin and not git-plugin at all.  It appears to be caused by this commit:

          commit de49c9bf21f560ac3851c4f7ea3a3597a114ac8e
          Author: Nicolas De Loof <nicolas.deloof@gmail.com>
          Date:   Tue Feb 24 09:44:20 2015 +0100
          
              [FIXED JENKINS-27097] use ISO-8601 in changelog
              Use an explicit format string (to mimic raw format)
              to enforce ISO-8601 date format.
              Side benefit is this format string should not be
              impacted if a future/exotic git CLI do introduce
              some subtle changes in format=raw output.

          Basically, an arbitary format was specified for the git whatchanged format:

          commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b

          The idea was good (to avoid changes in the format of the log pretty raw format), but it also introduced arbitrary wrapping early in the data processing which is probably not the correct place for it (altering the data during input).

          Changing this to:
          commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%s%n%n%b

          fixes the issue.

          I don't personally have the environment setup to test this fully, so if somebody can take this information and act upon it, I would be greatly appreciative.

          If there is the desire to maintain the existing (arbitrary) wrapping behaviour, then I would suggest adding some sort of flag that allows disabling the arbitrary wrapping.  This should (hopefully) make everybody happy

          Andrew Macks added a comment - - edited So, after tracking this issue for a while, and getting excited over the last couple of days with Chris' involvement, I got a little concerned when the issue became Unassigned again and decided to dig into it myself. It turns out that the issue is actually in git-client-plugin and not git-plugin at all.  It appears to be caused by this commit: commit de49c9bf21f560ac3851c4f7ea3a3597a114ac8e Author: Nicolas De Loof <nicolas.deloof@gmail.com> Date:   Tue Feb 24 09:44:20 2015 +0100     [FIXED JENKINS-27097] use ISO-8601 in changelog     Use an explicit format string (to mimic raw format)     to enforce ISO-8601 date format.     Side benefit is this format string should not be     impacted if a future /exotic git CLI do introduce     some subtle changes in format=raw output. Basically, an arbitary format was specified for the git whatchanged format: commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(76,4,4)%s%n%n%b The idea was good (to avoid changes in the format of the log pretty raw format), but it also introduced arbitrary wrapping early in the data processing which is probably not the correct place for it (altering the data during input). Changing this to: commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%s%n%n%b fixes the issue. I don't personally have the environment setup to test this fully, so if somebody can take this information and act upon it, I would be greatly appreciative. If there is the desire to maintain the existing (arbitrary) wrapping behaviour, then I would suggest adding some sort of flag that allows disabling the arbitrary wrapping.  This should (hopefully) make everybody happy

          andypoo please don't assign me issue without first discussing this with me. 

          I indeed worked on this in the past but don't have bandwidth to look into this anymore

          Nicolas De Loof added a comment - andypoo please don't assign me issue without first discussing this with me.  I indeed worked on this in the past but don't have bandwidth to look into this anymore

          Andrew Macks added a comment -

          Nicolas: My sincerest apologies for that.  I assigned it to you given the previous commit and regression.

          I'll continue looking into it directly myself.  It seems that my previous suggestion does not work when compiled into the plugin (still investigating why locally).

          Thanks.

          Andrew Macks added a comment - Nicolas: My sincerest apologies for that.  I assigned it to you given the previous commit and regression. I'll continue looking into it directly myself.  It seems that my previous suggestion does not work when compiled into the plugin (still investigating why locally). Thanks.

          Andrew Macks added a comment -

          So, my mistake was not to account for the indentation that was added in addition to the wrapping.

          This format works correctly:

          commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(0,4,4)%s%n%n%b

          Andrew Macks added a comment - So, my mistake was not to account for the indentation that was added in addition to the wrapping. This format works correctly: commit %H%ntree %T%nparent %P%nauthor %aN <%aE> %ai%ncommitter %cN <%cE> %ci%n%n%w(0,4,4)%s%n%n%b

          Not released yet

          Jose Blas Camacho Taboada added a comment - Not released yet

          Randy Jones added a comment -

          What's happening with this issue? Is there a version of the plugin with this change?

          Randy Jones added a comment - What's happening with this issue? Is there a version of the plugin with this change?

          Mark Waite added a comment - - edited

          randy_jones versions of the plugin with this change are available from the experimental update center. Current versions are git client plugin 3.0.0-beta7 and git plugin 4.0.0-beta7.

          Several blocking compatibility problems were detected by earlier testing of pre-release versions of git client plugin 3.0 and git plugin 4.0. Released versions of those plugins won't be available until the blocking problems are resolved. Those blocking issues are described in the git client plugin 3.0 milestone and in the git plugin 4.0 milestone.

          We'd love to have more users running the beta versions of those plugins.

          Mark Waite added a comment - - edited randy_jones versions of the plugin with this change are available from the experimental update center . Current versions are git client plugin 3.0.0-beta7 and git plugin 4.0.0-beta7. Several blocking compatibility problems were detected by earlier testing of pre-release versions of git client plugin 3.0 and git plugin 4.0. Released versions of those plugins won't be available until the blocking problems are resolved. Those blocking issues are described in the git client plugin 3.0 milestone and in the git plugin 4.0 milestone . We'd love to have more users running the beta versions of those plugins.

          Mark Waite added a comment -

          Released with git client plugin 3.0.0 and git plugin 4.0.0 on Nov 2, 2019.

          Mark Waite added a comment - Released with git client plugin 3.0.0 and git plugin 4.0.0 on Nov 2, 2019.

            jtaboada Jose Blas Camacho Taboada
            lars_francke Lars Francke
            Votes:
            8 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: