-
Notifications
You must be signed in to change notification settings - Fork 141
[JENKINS-43786] Adapted the administrative monitor to the new UI definition #70
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
Conversation
|
looks pretty 👍 |
|
@rtyler Thanks for your feedback. I've tried to provide an improvement in the UI by using a progressive enhancement approach. The previous one works and the maintainers will be able to adapt their plugins step by step. |
|
How does it look on Jenkins before the core PR? |
|
@daniel-beck I can prepare a screenshot but you can see an example jenkinsci/jenkins#2857 (comment). |
|
@recena To clarify, plugins that include a change like this one (i.e. the |
|
@daniel-beck This is a screenshot by using the changes on this PR and Jenkins LTS Although we could find some bad results. |
oleg-nenashev
left a comment
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.
alert and alert-warning CSS classes have been introduced in Jenkins 1.633. jenkinsci/jenkins@83a8d54
The plugin baseline is 1.625.x now. It is fine to bump the baseline IMHO, but it has to be done in order to make this PR acceptable.
🐛
|
@oleg-nenashev You can close this PR if you don't want to use this new design provided by the core. Nothing has been removed, hence, you can continue using the previus implementation. Maintainers can decide when starting to use this new UI design. |
|
@oleg-nenashev According to the stats, I don't see your concern like something critical 😄 |
|
@recena I do not understand how your response about "don't want" is related to my review feedback, please read it again.
|
|
@oleg-nenashev You agree, I was not clear with my explanation. What I wanted to say is the maintainer decides how and when he wants to adapt his plugin. Sure, I'm going to bump the baseline to |
Please use 1.642.3 LTS then. It's better to build against LTS releases, and nobody cares much about such old weeklys for sure |
| * @return If this version of the plugin is running on a Jenkins version where JENKINS-43786 is included. | ||
| */ | ||
| public boolean isTheNewDesignAvailable() { | ||
| if (Jenkins.getVersion().isNewerThan(new VersionNumber("2.88"))) { |
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.
2.88 is only an example. it depends when jenkinsci/jenkins#2857 is merged and released.
|
@oleg-nenashev @daniel-beck @jglick You can see one way on how the plugins could use jenkinsci/jenkins#2857 |
| * | ||
| * @return If this version of the plugin is running on a Jenkins version where JENKINS-43786 is included. | ||
| */ | ||
| public boolean isTheNewDesignAvailable() { |
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.
@Restricted(DoNotUse.class)
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.
@daniel-beck Done.
| </div> | ||
| <j:jelly xmlns:j="jelly:core"> | ||
|
|
||
| <j:if test="${!it.isTheNewDesignAvailable}"> |
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 just be made into a Groovy view so there's no change to plugin classes needed.
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.
@daniel-beck Agree although I'm not fan of Groovy for that purpose. I wanted to offer to two different examples. This one, and this jenkinsci/github-plugin#179, where the maintainers are already using Groovy.
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 am fine with a non-Groovy implementation. As we discussed with @recena in the chat, we rather need a macro or tag, which would check the Jenkins core version
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.
@oleg-nenashev Yes, a Jelly tag would be helpful. I'll find some of time for it.
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.
could use j:choose + j:when + j:otherwise
And should use a var to avoid code duplication
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.
@ndeloof A var for what?
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.
Remember, we are considering two cases just temporarily. When the baseline is updated, we don't need it.
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.
a var to define the css class to be used.
<j:choose>
<j:when test="${it.isTheNewDesignAvailable}">
<j:set var="css" value="warning">
</j:when>
<j:otherwise>
<j:set var="css" value="alert alert-warning">
</j:otherwise>
</j:choose>
<div class="${css}">
...makes me wonder, but it seems one could even use this simpler form:
<div class="${it.isTheNewDesignAvailable() ? 'alert alert-warning' : 'warning'}">
...by the way, using isNewDesignAvailable() as method name would allow to use property style notation ${it.isNewDesignAvailable} (adding "The" sounds weird to me).
I'm pretty sure this has been intensively investigated, but can't the CSS just target "warning" class efficiently enough within an administrative monitor context so all this isn't required ? I would understand this is required it he DOM structure was different, but here this sounds to only be a question of CSS alias.
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 seems to be you are not taking into account the paragraph <p>, needed in the first case.
By the way, as you can read in the article, this is temporal. It could be removed when the baseline is updated.
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.
And by the way, this is the simplest case where the content is more or less similar (but not identical). However, you will find more complex cases here jenkinsci/jenkins#2857
I don't see the value of using a var.
|
Is it dismissable? |
|
@lanwen No button for this one (even before), but there's an Administrative Monitors section on Configure System to disable or enable them individually. |
|
@lanwen As @daniel-beck has mentioned, I am not changing the functionality, only the appearance. |
|
@oleg-nenashev Could you update your review, please? |
oleg-nenashev
left a comment
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.
🐝 works for me, but it needs the Jenkins core release first
| */ | ||
| @Restricted(DoNotUse.class) | ||
| public boolean isTheNewDesignAvailable() { | ||
| if (Jenkins.getVersion().isNewerThan(new VersionNumber("2.88"))) { |
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 version needs to be updated to the actual one when upstream changes are integrated
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.
Sure, for that reason this PR is downstream of jenkinsci/jenkins#2857
|
@recena 2.103 has been released. Would you be able to update the PR so that we could ship it? |
oleg-nenashev
left a comment
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 tests are passing locally: it seems something related with the CI env. |
oleg-nenashev
left a comment
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 build failure is real 🐛
10:28:47 [linux-2.73.1] [INFO] Total bugs: 1
10:28:47 [linux-2.73.1] [INFO] Possible null pointer dereference in hudson.plugins.sshslaves.verifiers.MissingVerificationStrategyAdministrativeMonitor.isTheNewDesignAvailable() due to return value of called method [hudson.plugins.sshslaves.verifiers.MissingVerificationStrategyAdministrativeMonitor, hudson.plugins.sshslaves.verifiers.MissingVerificationStrategyAdministrativeMonitor] Dereferenced at MissingVerificationStrategyAdministrativeMonitor.java:[line 68]Known null at MissingVerificationStrategyAdministrativeMonitor.java:[line 68] NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE
|
Releasing new version without it |
|
@oleg-nenashev I don't know why I cannot see this error. I've checked the possible |
|
Restarted the CI build |

JENKINS-43786
Downstream of jenkinsci/jenkins#2857
Screenshot
@jenkinsci/code-reviewers