-
-
Notifications
You must be signed in to change notification settings - Fork 8.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a new summary description field for jobs #4489
Conversation
…] fixes for limiting the build history widget Reverts jenkinsci#4209
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.
seems like the most pragmatic approach and what will satisfy the most users
@Exported | ||
@CheckForNull | ||
public String getSummary() { | ||
return summary != null ? summary : getTruncatedDescription(); |
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.
do you need to check if it's empty, or will it always be safely null here?
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 would prefer a strict data model here (good for getter performance), but I can add String truncation on the setter side
* @return The length-limited description. | ||
* @deprecated truncated description uses arbitrary and unconfigurable limit of 100 symbols | ||
* @deprecated truncated description based on the {@link #TRUNCATED_DESCRIPTION_LIMIT} setting. | ||
*/ | ||
@Deprecated |
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.
should this be un deprecated?
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 no, because getSummary
is a proper API.
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.
Yes, I would prefer to not change the state here.
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 mentioned it as this PR adds documentation for it:
https://github.com/jenkinsci/jenkins/pull/4489/files#diff-c4f9931d88bca347279b881007d71f0eR234
Probably shouldn't be suggesting to call a deprecated API?
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.
when compiling, we will have a warning because we are calling a deprecated api. I don't have solution, just worse mentioning that this is intentional, no?
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 like this, assuming it will be possible to set summary via pipeline scripts. There are some bugs, though, thus marking PR as 'request changes'.
Additionally, you possibly want to allow editing of summary field on "Edit Build Information" page.
core/src/main/resources/hudson/widgets/HistoryWidget/entry.jelly
Outdated
Show resolved
Hide resolved
FTR introduction of a proper summary field is going to be an uphill battle. Jenkins core only includes the |
@@ -659,20 +679,42 @@ public final long getStartTimeInMillis() { | |||
return startTime; | |||
} | |||
|
|||
//TODO(oleg_nenashev): Do we want to export full description by default taking the size considerations? Looks like it should be another REST API or a flag |
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.
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.
Why would anything change for REST API? getDescription
always returned full text.
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.
That's why I do not touch it. But I believe that it is not ideal for users who are concerned about huge REST APIs
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.
No, I think we don't use it afaik.
But I would also discourage delivering the full description with the build object.
(Where it is only one build run, so less severe than the current job/build with/config page which load description from tons of builds.)
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.
Just decrease visibility if you don't like it here. People should be requesting it via ?tree
anyway.
More of a separate change though.
…uncation was introduced eons ago
|
Just my 5 ct: the summary field would be nice if starting from scratch. |
Ups, sorry, I overlooked that the summary takes the truncated description if empty. Just thought that this could be the solution, then saw it is already in your change :-D
|
If we add something to https://github.com/jenkinsci/workflow-support-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/support/steps/build/RunWrapper.java We will be able to set it from pipeline with But it's an uphill battle due to having to bump core unless you use reflection :/ |
This reminds me of the "Epic Story of Adding a Boolean Field to git-plugin": jenkinsci/git-plugin#792. 3 weeks, 15 PR iterations, 56 comments, 16 changed files and 200 lines of changes. Things should not be that much complex. |
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 have no particular opinions about this.
I'm not a particular fan of having HTML magic here. If someone uses a different formatter, is there a reasonable way for this magic to work?
public @Nonnull String getTruncatedDescription() { | ||
final int maxDescrLength = 100; | ||
if (description == null || description.length() < maxDescrLength) { | ||
public @CheckForNull String getTruncatedDescription() { |
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.
Wouldn't it be stylistically better to do:
@CheckForNull
public String ...
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.
It would. Just following the historical codestyle
Me too, but this is the current state of affairs. We could add a new |
Test failure is valid
|
The Sunday's weekly is getting delayed, so maybe we could try to get this into the weekly |
This one snuck up on me. Could I get a few more days to review? |
@daniel-beck sure |
*/ | ||
@Exported | ||
@CheckForNull | ||
public String getSummary() { |
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.
Should it have a suppressed warning for the use of a deprecated method?
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.
+1 for this proposal. IMO, this new summary field should have been in the model since the beginning
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.
We will be adding a deprecation warning at compile time, but it's not a big issue.
* @return The length-limited description. | ||
* @deprecated truncated description uses arbitrary and unconfigurable limit of 100 symbols | ||
* @deprecated truncated description based on the {@link #TRUNCATED_DESCRIPTION_LIMIT} setting. | ||
*/ | ||
@Deprecated |
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.
when compiling, we will have a warning because we are calling a deprecated api. I don't have solution, just worse mentioning that this is intentional, no?
It's called the build name. |
@daniel-beck do you still want to do a review? It is likely to miss the weekly. Looks like I will need to create a backportable version of a fix without new API |
@oleg-nenashev FWIW I consider jsoref#5 to be a nice standalone change, if you want something to make the LTS release less broken with long descriptions. |
Why doesn't the summary field show up on There's also the weird API model that makes it impossible for short descriptions to tell whether an identical summary is set, or whether the summary is just the description. I guess this is to make the sidepanel code easier, but is just confusing. There's also a bug where submitting I'm undecided whether the entire summary concept makes sense to me -- see #4489 (comment) -- but this implementation has problems. |
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.
As above.
Suggested changelog documents it as a developer change. I do not plan to work on the rest of frontend until we coordinate delivery for Pipeline. #4489 (comment)
It is. I will probably detach the bugfix and the rest for now |
New version is here: #4529 |
#4529 was merged. So is this still necessary? |
@oleg-nenashev shouldn't we close this PR as #4529 was merged? Thanks. |
Unfortunately, no plans to work on it anytime soon
…On Thu, Oct 1, 2020, 15:37 Adrien Lecharpentier ***@***.***> wrote:
@oleg-nenashev <https://github.com/oleg-nenashev> shouldn't we close this
PR as #4529 <#4529> was merged?
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4489 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAW4RIFB5EX3GGE5UHSOSZTSISA2BANCNFSM4KTCNPSA>
.
|
should we close this PR for now and you can re-open it when you have more time? |
I'm closing this PR for now, please reopen it when you will be able to work on it again. |
Draft implementation for my suggestion in #4477 which could be a solution which is acceptable to both sides (or not)
Proposed changelog entries
summary
field for runsProposed upgrade guidelines
N/A
Submitter checklist
Proposed changelog entries
section only if there are breaking changes or other changes which may require extra steps from users during the upgradeDesired reviewers
@mention
Maintainer checklist
Before the changes are marked as
ready-for-merge
:Proposed changelog entries
are correctupgrade-guide-needed
label is set and there is aProposed upgrade guidelines
section in the PR title. (example)lts-candidate