[JENKINS-43786] Adapted the administrative monitor to the new UI definition#70
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.
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.
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.
@Restricted(DoNotUse.class)
| </div> | ||
| <j:jelly xmlns:j="jelly:core"> | ||
|
|
||
| <j:if test="${!it.isTheNewDesignAvailable}"> |
There was a problem hiding this comment.
Should just be made into a Groovy view so there's no change to plugin classes needed.
There was a problem hiding this comment.
@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.
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.
@oleg-nenashev Yes, a Jelly tag would be helpful. I'll find some of time for it.
There was a problem hiding this comment.
could use j:choose + j:when + j:otherwise
And should use a var to avoid code duplication
There was a problem hiding this comment.
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.
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.
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.
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.
🐝 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.
This version needs to be updated to the actual one when upstream changes are integrated
There was a problem hiding this comment.
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? |
|
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.
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