[JIRA] [git-plugin] (JENKINS-29977) Git Plugin truncates changelog

28 views
Skip to first unread message

jenkins@lars-francke.de (JIRA)

unread,
Aug 17, 2015, 7:22:05 AM8/17/15
to jenkinsc...@googlegroups.com
Lars Francke created an issue
 
Jenkins / Bug JENKINS-29977
Git Plugin truncates changelog
Issue Type: Bug Bug
Assignee: Nicolas De Loof
Attachments: Correct.png, Problem1.png, Problem2.png
Components: git-plugin
Created: 17/Aug/15 11:20 AM
Environment: 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
Priority: Major Major
Reporter: Lars Francke

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.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 18, 2015, 11:49:03 PM8/18/15
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-29977
 
Re: Git Plugin truncates changelog

Can you identify which plugin release was the last version you used which did not truncate?

I see the truncation, but rather assume it has been that way for a long time.

I think that truncation is not unreasonable, considering the recommendation for 50/72 formatting on stackoverflow, Chris Beams blog, Tim Pope's blog, and Caleb Thompson. I'm not aware of a change which intentionally truncated the commit message for display, but I see the truncation is happening.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 18, 2015, 11:50:01 PM8/18/15
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-29977
Can you identify which plugin release was the last version you used which did not truncate?

I see the truncation, but rather assume it has been that way for a long time.

I think that truncation is not unreasonable, considering the recommendation for [50/72 formatting on stackoverflow|http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting], [ linux kernel recommendations|http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=HEAD#l521], [ Chris Beams blog|http://chris.beams.io/posts/git-commit/], [Tim Pope's blog|http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html], and [Caleb Thompson|https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message].  I'm not aware of a change which intentionally truncated the commit message for display, but I see the truncation is happening.

jenkins@lars-francke.de (JIRA)

unread,
Aug 20, 2015, 6:55:01 PM8/20/15
to jenkinsc...@googlegroups.com

Thanks for the comment Mark. As you can see from the screenshot the truncation has been introduced recently (sometime this year, took me a while to notice).

I have tried a few versions back to 2.2.6 but it still happens there. I will try and ask the Apache folks which versions they are running.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 21, 2015, 7:56:02 AM8/21/15
to jenkinsc...@googlegroups.com

I'm not persuaded that it happened in the last year, since 2.2.6 was released Sep 2014 and you indicate that it is already there in 2.2.6. My initial suspicion is that the version which does not truncate is from the 1.x release series from a long time ago. However, I'm open to being proven wrong on that.

jenkins@lars-francke.de (JIRA)

unread,
Aug 24, 2015, 6:48:01 PM8/24/15
to jenkinsc...@googlegroups.com

You could very well be correct, yes. Next chance I get I'll try to downgrade to a 1.x version.

jenkins@lars-francke.de (JIRA)

unread,
Aug 27, 2015, 4:25:01 AM8/27/15
to jenkinsc...@googlegroups.com

I've tried 1.5 and you're correct: That does not truncate.

So I have a workaround for now but to me this still seems undesirable and like a bug. If you do agree - and I'm not sure about that - I'm happy to take a look at the code to see if I can find what's going on.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 6, 2015, 9:30:01 AM9/6/15
to jenkinsc...@googlegroups.com

I prefer the current behavior of only showing a reasonable subset of the commit message in the UI presentation. My rationale is captured in my earlier comment on this bug. Other maintainers may have a different opinion, but for me, I prefer the truncation that was implemented in the 2.0 plugin rather than returning to the 1.0 unlimited length string behavior.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 6, 2015, 9:31:01 AM9/6/15
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-29977
I prefer the current behavior of only showing a reasonable subset of the commit message in the UI presentation.  My rationale is captured in my [earlier comment on this bug|https://issues.jenkins-ci.org/browse/JENKINS-29977?focusedCommentId= 235049 234786 &page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment- 235049 234786 ].  Other maintainers may have a different opinion, but for me, I prefer the truncation that was implemented in the 2.0 plugin rather than returning to the 1.0 unlimited length string behavior.

jenkins@lars-francke.de (JIRA)

unread,
Sep 6, 2015, 1:27:01 PM9/6/15
to jenkinsc...@googlegroups.com

Thanks Mark. Shall I close the issue then?

(It seems as if 1.5 doesn't always work as it used to either, so I'll have to find alternatives to Jenkins anyway)

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 6, 2015, 8:38:03 PM9/6/15
to jenkinsc...@googlegroups.com

I think you should close the issue. If you're passionate about not truncating and willing to invest some effort in the plugin, you could consider creating a separate plugin (to add the behavior for those users who want it) or an optional extension of the current plugin which would modify the behavior to never truncate the change log message.

jenkins@lars-francke.de (JIRA)

unread,
Sep 7, 2015, 1:15:07 AM9/7/15
to jenkinsc...@googlegroups.com
Lars Francke closed an issue as Not A Defect
Change By: Lars Francke
Status: Open Closed
Resolution: Not A Defect

jerry.lumpkins@gmail.com (JIRA)

unread,
Oct 14, 2015, 3:17:03 PM10/14/15
to jenkinsc...@googlegroups.com

My QA department is beside themselves over the shortened comments.
They use these to document our changes, and this latest update has completely broken that.
We really want the comment to be as long as it is.
What is the value of truncating it? Could this at least be optional?

jerry.lumpkins@gmail.com (JIRA)

unread,
Oct 14, 2015, 3:19:03 PM10/14/15
to jenkinsc...@googlegroups.com
Jerry Lumpkins reopened an issue
 

I would really like to discuss this with you. I'm not understanding the value to anyone of truncating the messages. We really want to see the entire thing.
Change By: Jerry Lumpkins
Resolution: Not A Defect
Status: Closed Reopened

jerry.lumpkins@gmail.com (JIRA)

unread,
Oct 14, 2015, 4:01:02 PM10/14/15
to jenkinsc...@googlegroups.com
Jerry Lumpkins edited a comment on Bug JENKINS-29977
I would really like to discuss this with you. I'm not understanding the value to anyone of truncating the messages. We really want to see the entire thing.


I was looking for your earlier comment that was referenced above, and I can't find it. Would you settle for at least allowing a few hundred characters?

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 14, 2015, 8:30:02 PM10/14/15
to jenkinsc...@googlegroups.com

Jerry Lumpkins I'm sorry that your QA department is concerned about the shortened first line of the commit message in the message summary presentation. I believe it was done to keep the user interface from being mangled by long commit messages. It follows a pattern similar to the pattern used by GitHub (see this example) and gitweb (the web interface provided by the git project).

The community recommendations on git commit messages match with the behavior of the plugin. The recommendation is 50/72 formatting on stackoverflow, linux kernel recommendations, Chris Beams blog, Tim Pope's blog, and Caleb Thompson.

I am surprised your QA department was not also demanding the entire text of the commit message, since that is another form of truncation, and I believe that form of truncation was (I believe) already included in the earliest versions of the plugin.

I'm not willing to change so long-standing a behavior in the plugin without many more users complaining about it. I would expect many more complaints with it unlimited length than have ever been received due to the truncation.

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 14, 2015, 8:31:08 PM10/14/15
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-29977
[~jlumpkins] I'm sorry that your QA department is concerned about the shortened first line of the commit message in the message summary presentation.  I believe it was done to keep the user interface from being mangled by long commit messages.  It follows a pattern similar to the pattern used by GitHub (see [this example|https://github.com/jenkinsci/git-plugin/commit/e84633092b022278367d95ae48d387a4ee7ab1e2]) and gitweb (the web interface provided by the git project).

The community recommendations on git commit messages match with the behavior of the plugin.  The recommendation is [50/72 formatting on stackoverflow|http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting], [linux kernel recommendations|http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=HEAD#l521], [Chris Beams blog|http://chris.beams.io/posts/git-commit/], [Tim Pope's blog|http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html], and [Caleb Thompson|https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message].


I am surprised your QA department was not also demanding the entire text of the commit message, since that is another form of truncation, and I believe that form of truncation was (I believe) already included in the earliest versions of the plugin.

I'm not willing to change so long-standing a behavior in the plugin without many more users complaining about it.  I would expect many more complaints with it unlimited length than have ever been received due to the truncation.


If your QA department needs the full text of the commit message for a specific commit, why not configure the Jenkins job to use a repository browser for your organization, and point that repository browser to your git repository?

ryan@mymilligan.com (JIRA)

unread,
Jun 15, 2016, 12:03:02 PM6/15/16
to jenkinsc...@googlegroups.com

I would also like to see the full commit messages being output from the plugin. Let the length of the commit message be determined by the source system or team, not the consuming system. Other source control plugins (i.e.: TFS) provide the full commit/changeset message without any problems. While the community may recommend a specific length, plugins that consume the data shouldn't be the part of the process that enforces it.
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

jerry.lumpkins@gmail.com (JIRA)

unread,
Jun 15, 2016, 12:18:01 PM6/15/16
to jenkinsc...@googlegroups.com

It's been a while since I thought about this, but thanks for reminding me.

I agree with Ryan Milligan that the consumer of the data shouldn't truncate it arbitrarily.

Also, reviewing the comments on the site referenced: http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting I think you will find many other users that do not agree.

When you create an open source project that gains wide acceptance it seems like you have some responsibility to those that have come to depend on it to not make arbitrary changes that break reasonable work flows that rely on your project. The attitude that you wrote it, so if I don't like how you changed it, I should branch it and do it myself is not generally the spirit of the open source community.

gkilleen@gmail.com (JIRA)

unread,
Aug 12, 2016, 10:33:04 AM8/12/16
to jenkinsc...@googlegroups.com

If I can chime in, we use the Jira plugin to parse out Jira IDs from git commit messages to move the tickets through the workflow, and the truncated message has been an issue for us. For example, we'll have a git commit message, similar to

[AND-5186]: Fixes for Spanish Strings. Also: AND-5185, AND-5187, AND-5188, AND-5189, AND-5190

And in this particular case, it only processed 5185 and 5186 and not the others because of the truncation.

So yeah, if there's a way to preserve the entire commit message, would be a huge help.

thanks!

radek.antoniuk@quiddia.com (JIRA)

unread,
Aug 13, 2016, 5:51:02 PM8/13/16
to jenkinsc...@googlegroups.com

I'm quite surprised with the discussion and approach on this.
I'm maintaining the jira-plugin and as mentioned earlier, it depends on parsing the commit message.
The commit message is an integral part of a commit and should not be arbitrarily consumed by a plugin which role is to be an interface to git repository. References to github web UI or gitweb (again, web UI) are wrong as the purpose of those web UIs are different than a plugin that is a git provider.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 13, 2016, 6:15:04 PM8/13/16
to jenkinsc...@googlegroups.com

Radek Antoniuk I'm not sure how the Jira plugin requests the commit messages. It seems (from Gerald Killeen's description) that the Jira plugin is reading the trimmed form of the commit messages as they are presented in the user interface, instead of using the git client plugin methods to collect the commit message from the git repository.

How does the Jira plugin request the commit messages?

The git client plugin (which provides API access to git repositories) provides various "changelog" methods which return changelog entries for ranges of commits. As far as I know, those API calls don't truncate. The truncation happens (as far as I recall) in the git plugin layer prior to presentation in the user interface.

mark.earl.waite@gmail.com (JIRA)

unread,
Aug 13, 2016, 6:18:02 PM8/13/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-29977
[~warden] I'm not sure how the Jira plugin requests the commit messages.  It seems (from [~gkilleen]'s [description|https://issues.jenkins-ci.org/browse/JENKINS-29977?focusedCommentId=266766&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-266766]) that the Jira plugin is reading the trimmed form of the commit messages as they are presented in the user interface, instead of using the git client plugin methods to collect the commit message from the git repository.


How does the Jira plugin request the commit messages?

The git client plugin (which provides API access to git repositories) provides various "changelog" methods which return changelog entries for ranges of commits.  As far as I know, those API calls don't truncate.  The truncation happens (as far as I recall) in the git plugin layer prior to presentation in the user interface.


The git plugin provides a user interface (recent changes list, links to source repositories, etc.) and workflow elements (submodule support, sparse checkout configuration, tagging, pushing commits back to the remote repository, etc.)

patrick.m.carson@gmail.com (JIRA)

unread,
Sep 16, 2016, 2:07:04 PM9/16/16
to jenkinsc...@googlegroups.com

Mark,

Would this be a feature that would be difficult to make configurable? As you said its a recommendation, not a standard, and the recommendation is only a style preference. I'm sure there are many people out there who would like to be able to see the full change log at a glance even if it was a checkbox or update to a configuration.

ryan@mymilligan.com (JIRA)

unread,
Sep 16, 2016, 2:13:01 PM9/16/16
to jenkinsc...@googlegroups.com

I agree with Patrick. If this could be made configurable, with the default behavior being the current behavior, those of us that would prefer the full commit message could then toggle to option on the git plugin.

aheritier@apache.org (JIRA)

unread,
Sep 26, 2016, 1:48:02 PM9/26/16
to jenkinsc...@googlegroups.com
Arnaud Héritier assigned an issue to Unassigned
Change By: Arnaud Héritier
Assignee: Nicolas De Loof

aheritier@apache.org (JIRA)

unread,
Sep 26, 2016, 1:56:02 PM9/26/16
to jenkinsc...@googlegroups.com

AFAIU the comment includes only the first line like many others tools are doing ?
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L233

aheritier@apache.org (JIRA)

unread,
Sep 27, 2016, 3:10:02 AM9/27/16
to jenkinsc...@googlegroups.com
Arnaud Héritier updated an issue
Change By: Arnaud Héritier
Comment:
AFAIU the comment includes only the first line like many others tools are doing ?
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitChangeSet.java#L233

aheritier@apache.org (JIRA)

unread,
Sep 27, 2016, 3:12:01 AM9/27/16
to jenkinsc...@googlegroups.com

AFAIU the changes page at the project level only display the commit title (it is supposed to be its first line) while the changes page at the build level contains everything. And thus users would like to have all the logs in the changes page at the project level ?

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 27, 2016, 6:14:09 AM9/27/16
to jenkinsc...@googlegroups.com

Arnaud Héritier the project level changes page displays the first line of the commit up to a certain number of characters. If the first line of the commit is longer than that certain number of characters, it is truncated in the project level view of the changes. The 1.x releases of the plugin would display the entire first line of the commit, no matter how many characters it contained.

aheritier@apache.org (JIRA)

unread,
Sep 27, 2016, 12:56:06 PM9/27/16
to jenkinsc...@googlegroups.com

Hi Mark Waite

Thanks a lot for your feedback. Thus it is a feature.
I had a look at the code and found the management of the commit title (first line)

Which isn't the case for others SCMs like the subversion plugin

But I wasn't able to find where the line is truncated in the git plugin ..

Do you think that it may be an interesting improvement to allow configure the behavior (to not truncate the title line and to allow to display all the lines) ?

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 1, 2016, 7:19:01 AM10/1/16
to jenkinsc...@googlegroups.com

I would have no objection to a configurable behavior that would allow the full title line for those users who want things displayed the way git plugin 1.x did.

kloehnc@msoe.edu (JIRA)

unread,
Feb 9, 2018, 12:08:05 AM2/9/18
to jenkinsc...@googlegroups.com
Chris Kloehn assigned an issue to Chris Kloehn
Change By: Chris Kloehn
Assignee: Chris Kloehn
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

kloehnc@msoe.edu (JIRA)

unread,
Feb 9, 2018, 12:08:05 AM2/9/18
to jenkinsc...@googlegroups.com
Chris Kloehn started work on Bug JENKINS-29977
 
Change By: Chris Kloehn
Status: Open In Progress

kloehnc@msoe.edu (JIRA)

unread,
Feb 9, 2018, 12:11:02 AM2/9/18
to jenkinsc...@googlegroups.com

Mark Waite This is one of the first issues I plan to tackle in the git-plugin. Since you are more familiar with the code base, do you know where (or roughly where) I would start to look for this truncating feature? 

Thank you in advance!

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 9, 2018, 8:36:02 AM2/9/18
to jenkinsc...@googlegroups.com

Chris Kloehn thanks for your willingness to help with the code. That is great!

Refer to the changeset jelly snippet which generates the changelog. That jelly script uses the "it" variable to iterate over the GitChangeSetList.changeSets using the getLogs() method. That uses a ChangeLogSet to call the GitChangeSet.getMsg(). That uses GitChangeSet.parseCommit() to parse the commit and take the first line of the commit message as the summary.

I suspect the constructor for the GitChangeSet is receiving a list of strings which are wrapped (probably by format arguments passed to command line git) and the use of the first line of the commit message is what causes the truncation.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 9, 2018, 8:48:03 AM2/9/18
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-29977
[~ckloehn] thanks for your willingness to help with the code.  That is great!

Refer to the [changeset jelly snippet|https://github.com/jenkinsci/git-plugin/blob/git-3.7.0/src/main/resources/hudson/plugins/git/GitChangeSetList/index.jelly#L11] which generates the changelog.  That jelly script uses the "[it|https://wiki.jenkins.io/display/JENKINS/Basic+guide+to+Jelly+usage+in+Jenkins#BasicguidetoJellyusageinJenkins-Understandingtheitobject]" variable to iterate over the [GitChangeSetList.changeSets|https://github.com/jenkinsci/git-plugin/blob/git-3.7.0/src/main/java/hudson/plugins/git/GitChangeSetList.java#L37] using the getLogs() method.  That uses a [ChangeLogSet|https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/scm/ChangeLogSet.java] to call the [GitChangeSet.getMsg()|https://github.com/jenkinsci/git-plugin/blob/git-3.7.0/src/main/java/hudson/plugins/git/GitChangeSet.java#L482].  That uses [GitChangeSet.parseCommit()|https://github.com/jenkinsci/git-plugin/blob/git-3.7.0/src/main/java/hudson/plugins/git/GitChangeSet.java#L233] to parse the commit and take the first line of the commit message as the summary.


I suspect the constructor for the GitChangeSet is receiving a list of strings which are wrapped (probably by format arguments passed to command line git) and the use of the first line of the commit message is what causes the truncation.


You might refer to [GitChangeLogParserTest|https://github.com/jenkinsci/git-plugin/blob/git-3.7.0/src/test/java/hudson/plugins/git/GitChangeLogParserTest.java#L13] as a place to start your exploration with a debugger.  Ultimately, I think you'll need to find the location in the code (probably in git client plugin) where arguments are passed to the command line git (and JGit) to format the list of changes for parsing by GitChangeLogParser.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 10, 2018, 4:14:03 PM2/10/18
to jenkinsc...@googlegroups.com


I also created a [regression test|https://github.com/MarkEWaite/jenkins-bugs/tree/JENKINS-29977] in my jenkins-bugs repository.  I suspect that regression test needs more surrounding setup than you want to provide, but it is available if you need it.  I use that regression test job in my [Docker image|https://github.com/MarkEWaite/docker-lfs/tree/lts-with-plugins] to detect end to end behavior regressions.

kloehnc@msoe.edu (JIRA)

unread,
Feb 13, 2018, 12:21:03 PM2/13/18
to jenkinsc...@googlegroups.com

Mark Waite Sorry if this is a bad question, but is there a way I can run the plugin locally with my own instance of jenkins to test things?

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 13, 2018, 12:28:02 PM2/13/18
to jenkinsc...@googlegroups.com

Chris Kloehn that's a very good question. Refer to the jenkins.io plugin development section for an overview of plugin development. If you can't find what you need there, look at the older plugin tutorial and the debugging a plugin section for good pointers.

kloehnc@msoe.edu (JIRA)

unread,
Feb 13, 2018, 4:52:02 PM2/13/18
to jenkinsc...@googlegroups.com

Mark Waite one last question about getting the project to build, I opened the pom.xml file with intellij and attempted a build. Unfortunately I could not find the package "hudson.plugins.git.Messages" so the project wouldn't build. I have done some searching for the file with little luck. Do you know where I might find it?

kloehnc@msoe.edu (JIRA)

unread,
Feb 13, 2018, 4:53:02 PM2/13/18
to jenkinsc...@googlegroups.com
Chris Kloehn edited a comment on Bug JENKINS-29977
[~markewaite] one last question about getting the project to build, I opened the pom.xml file with intellij and attempted a build. Unfortunately I could not find the package "hudson.plugins.git.Messages" so the project wouldn't build. I have done some searching for the file with little luck. Do you know where I might find it?

 

The file looking for the "Messages" package is AncestryBuildChooser 

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 13, 2018, 5:11:02 PM2/13/18
to jenkinsc...@googlegroups.com

The "Messages" classes are generated by maven at compile time. You might refer to Intellij for Jenkins or you might try compiling that project from the command line first (using Maven 3.5.0 or later - I use Maven 3.5.2).

kloehnc@msoe.edu (JIRA)

unread,
Feb 13, 2018, 5:30:02 PM2/13/18
to jenkinsc...@googlegroups.com

a command line build is what I tried at first. however this also threw errors at me for some files it couldn't find. Specifically these two files were: 

git-plugin\target\classes\META-INF\annotations\hudson.Extension, and git-plugin\target\classes\META-INF\exposed.stapler-beans. 

I will take a look at the Intellij for Jenkins and see if that helps.

 

 

kloehnc@msoe.edu (JIRA)

unread,
Feb 13, 2018, 6:11:04 PM2/13/18
to jenkinsc...@googlegroups.com

So I was able to get a successful build out of Intelllij, but it did not produce an .hpi file. My command line is still not wanting to build properly and because of that I am not finding a way to debug the plugin as suggested at the  debugging a plugin section. Thank you for all the help thus far Mark Waite

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 13, 2018, 6:37:02 PM2/13/18
to jenkinsc...@googlegroups.com

Here is the output I see from commands that I used:

private@wheezy64b:~/tmp$ git clone https://github.com/jenkinsci/git-plugin
Cloning into 'git-plugin'...
remote: Counting objects: 25687, done.
remote: Total 25687 (delta 0), reused 0 (delta 0), pack-reused 25687
Receiving objects: 100% (25687/25687), 5.22 MiB | 8.65 MiB/s, done.
Resolving deltas: 100% (9883/9883), done.
private@wheezy64b:~/tmp$ cd git-plugin/
private@wheezy64b:~/tmp/git-plugin$ mvn --version
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_161, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.0-5-amd64", arch: "amd64", family: "unix"
private@wheezy64b:~/tmp/git-plugin$ mvn clean install

At that point, a chunk of the internet is downloaded to my local cache.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 13, 2018, 6:38:03 PM2/13/18
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-29977
Here is the output I see from commands that I used:

{noformat}
private@ wheezy64b stretch :~/tmp$ git clone https://github.com/jenkinsci/git-plugin

Cloning into 'git-plugin'...
remote: Counting objects: 25687, done.
remote: Total 25687 (delta 0), reused 0 (delta 0), pack-reused 25687
Receiving objects: 100% (25687/25687), 5.22 MiB | 8.65 MiB/s, done.
Resolving deltas: 100% (9883/9883), done.
private@ wheezy64b stretch :~/tmp$ cd git-plugin/
private@ wheezy64b stretch :~/tmp/git-plugin$ mvn --version

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_161, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.9.0-5-amd64", arch: "amd64", family: "unix"
private@ wheezy64b stretch :~/tmp/git-plugin$ mvn clean install
{noformat}


At that point, a chunk of the internet is downloaded to my local cache.

kloehnc@msoe.edu (JIRA)

unread,
Feb 13, 2018, 7:03:03 PM2/13/18
to jenkinsc...@googlegroups.com

I have a similar output 

 

C:\Users\kloehnc\Desktop\temp>git clone https://github.com/kloehnc/git-plugin.git
Cloning into 'git-plugin'...
remote: Counting objects: 25687, done.
remote: Total 25687 (delta 0), reused 0 (delta 0), pack-reused 25687
Receiving objects: 100% (25687/25687), 5.22 MiB | 1.04 MiB/s, done.
Resolving deltas: 100% (9883/9883), done.
C:\Users\kloehnc\Desktop\temp>cd git-plugin
C:\Users\kloehnc\Desktop\temp\git-plugin>mvn --version
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T02:58:13-05:00)
Maven home: C:\Program Files\Apache\maven\apache-maven-3.5.2\bin\..
Java version: 9.0.4, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk-9.0.4
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
C:\Users\kloehnc\Desktop\temp\git-plugin>mvn clean install

However its the clean install that fails with no such file exceptions 

 

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 13, 2018, 8:21:02 PM2/13/18
to jenkinsc...@googlegroups.com

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.

kloehnc@msoe.edu (JIRA)

unread,
Feb 13, 2018, 8:29:03 PM2/13/18
to jenkinsc...@googlegroups.com

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. 

kloehnc@msoe.edu (JIRA)

unread,
Feb 14, 2018, 8:12:04 AM2/14/18
to jenkinsc...@googlegroups.com
Chris Kloehn stopped work on Bug JENKINS-29977
 
Change By: Chris Kloehn
Status: In Progress Open

kloehnc@msoe.edu (JIRA)

unread,
Feb 14, 2018, 8:12:05 AM2/14/18
to jenkinsc...@googlegroups.com
Chris Kloehn started work on Bug JENKINS-29977
 
Change By: Chris Kloehn
Status: Open In Progress

kloehnc@msoe.edu (JIRA)

unread,
Feb 14, 2018, 11:48:03 AM2/14/18
to jenkinsc...@googlegroups.com
Chris Kloehn assigned an issue to Unassigned
 
Jenkins / Bug JENKINS-29977
Git Plugin truncates changelog
Change By: Chris Kloehn
Assignee: Chris Kloehn

kloehnc@msoe.edu (JIRA)

unread,
Feb 14, 2018, 11:48:03 AM2/14/18
to jenkinsc...@googlegroups.com
Chris Kloehn stopped work on Bug JENKINS-29977
 
Change By: Chris Kloehn
Status: In Progress Open

andypoo@gmail.com (JIRA)

unread,
Feb 14, 2018, 4:58:04 PM2/14/18
to jenkinsc...@googlegroups.com

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...@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@gmail.com (JIRA)

unread,
Feb 14, 2018, 4:59:02 PM2/14/18
to jenkinsc...@googlegroups.com
Andrew Macks edited a comment on Bug JENKINS-29977
{{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:}}
 {{}}

{code:java}

commit de49c9bf21f560ac3851c4f7ea3a3597a114ac8e
Author: Nicolas De Loof <nicolas...@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.{code}
{{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@gmail.com (JIRA)

unread,
Feb 21, 2018, 7:53:03 AM2/21/18
to jenkinsc...@googlegroups.com
Andrew Macks assigned an issue to Nicolas De Loof
Change By: Andrew Macks
Assignee: Nicolas De Loof

nicolas.deloof@gmail.com (JIRA)

unread,
Feb 21, 2018, 7:57:02 AM2/21/18
to jenkinsc...@googlegroups.com
Nicolas De Loof assigned an issue to Mark Waite
Change By: Nicolas De Loof
Assignee: Nicolas De Loof Mark Waite

nicolas.deloof@gmail.com (JIRA)

unread,
Feb 21, 2018, 7:59:03 AM2/21/18
to jenkinsc...@googlegroups.com

Andrew Macks 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

andypoo@gmail.com (JIRA)

unread,
Feb 21, 2018, 8:43:03 AM2/21/18
to jenkinsc...@googlegroups.com

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.

andypoo@gmail.com (JIRA)

unread,
Feb 21, 2018, 9:00:03 AM2/21/18
to jenkinsc...@googlegroups.com

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

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 21, 2018, 12:42:03 PM2/21/18
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
Change By: Mark Waite
Assignee: Mark Waite

jtaboada@cloudbees.com (JIRA)

unread,
Oct 10, 2018, 3:55:02 AM10/10/18
to jenkinsc...@googlegroups.com
Change By: Jose Blas Camacho Taboada
Assignee: Jose Blas Camacho Taboada
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

jtaboada@cloudbees.com (JIRA)

unread,
Dec 3, 2018, 8:08:03 AM12/3/18
to jenkinsc...@googlegroups.com
Status: Open In Progress

jtaboada@cloudbees.com (JIRA)

unread,
Dec 3, 2018, 8:09:04 AM12/3/18
to jenkinsc...@googlegroups.com
Status: In Progress Review

jtaboada@cloudbees.com (JIRA)

unread,
Dec 3, 2018, 8:10:03 AM12/3/18
to jenkinsc...@googlegroups.com
 

Not released yet
Status: In Review Resolved
Resolution: Fixed

randy@jonesrc.com (JIRA)

unread,
Mar 14, 2019, 5:45:03 PM3/14/19
to jenkinsc...@googlegroups.com

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

mark.earl.waite@gmail.com (JIRA)

unread,
Mar 14, 2019, 6:12:02 PM3/14/19
to jenkinsc...@googlegroups.com

Randy Jones versions of the plugin with this change are available from the[ experimental update center|https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/]. 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.earl.waite@gmail.com (JIRA)

unread,
Mar 14, 2019, 6:12:04 PM3/14/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-29977
[~randy_jones] versions of the plugin with this change are available from the[ experimental update center|https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/].  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 |https://github.com/jenkinsci/git-client-plugin/milestone/1]and in the [git plugin 4.0 milestone|https://github.com/jenkinsci/git-plugin/milestone/3].


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

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 20, 2019, 6:16:04 AM10/20/19
to jenkinsc...@googlegroups.com
Change By: Mark Waite
Status: Resolved Fixed but Unreleased
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 2, 2019, 8:08:04 AM11/2/19
to jenkinsc...@googlegroups.com
 

Released with git client plugin 3.0.0 and git plugin 4.0.0 on Nov 2, 2019.
Change By: Mark Waite
Status: Fixed but Unreleased Closed
Reply all
Reply to author
Forward
0 new messages