Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[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.
- Loading branch information
Showing
2 changed files
with
14 additions
and
3 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I deployed a pre-release version of the git client plugin onto my work server which included this change. I think this change may be what caused one of my previously functioning jobs to fail with the stack trace:
I will investigate further as time allows. My first attempt will be to revert this change on a private branch, just to see if that resolves the issue. If it does, then I may investigate further to write a test which exercises the failure. If I'm successful at writing the failing test, then I might try fixing the problem.
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarkEWaite ok, thanks for investigating on this. Can you also please run git log with the same format string and paste here to compare the actual output with expected ISO format ?
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will attempt it. My initial test was to run the same job again.
The second time I ran the job (a multi-configuration job), it moved the error message from the flyweight executor's log to the logs in the jobs in the various configurations. The error message disappeared from the flyweight job.
The third time I ran the job, it resolved the error message from most of the configurations. A few (one or two) failed, but most succeeded.
The fourth time I ran the job, the error message was resolved in all configurations.
I'll attempt to print changelog entries from all the changes in the repository I was using, in case the problem is somehow specific to the changelog of that repository.
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created a custom build based on git plugin 2.3.5 (see this branch - knowing that I'll delete that branch in a week or two...)
With that change applied to my running Jenkins, GitChangeSet code reported:
I think that means the check for ISO 8601 format in the git plugin needs to do more than a length check before deciding to skip the parsing and formatting.
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the standard indeed both defines +hhmi and +hh:mi, also Z could be used by people using UTC
I suggest we use:
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're going in the right direction with that proposed change, but I don't think it will handle the case that exists in the current code. In the current code, the pattern is assumed to be a sequence of digits followed by a space followed by what I believe is assumed to be time zone information.
The NumberUtils.isDigits(s) test will cause that sequence of digits, a space, and time zone, to now return the string without formatting it as an ISO-8601 date format.
How about:
I need more time to think about that proposed rework, and more time to write tests around the various conditions which can exist. There is already at least one bug reporting that the date information returned by one of the API calls is incorrect. This seems like the chance to write several tests around that bug and confirm that it is fixed and remains fixed.
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this assumes timezone will always be set. I suggest :
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I like that way of expressing the solution very much.
I'd really like tests around that code before we make a change, but the problem may already exist in the interaction between git-plugin 2.3.5 and git-client-plugin 1.16.1. We may not have time to wait for me to write tests of the various combinations of date and time zone. I've seen this code break my builds in several different cases, on different Jenkins servers. I suspect we don't have very long before other users will encounter the same problem I encountered.
Will you have time to write some tests of that code?
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can do this early next week.
de49c9b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!