-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
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
[JENKINS-69339] Add support for badge icons in Management links #6995
Conversation
Allow to define a badge icon and a tooltip for all management links
fix compile errors
The weird thing about the existing badge is that it only exists for a feature that does not have a corresponding admin monitor (plugin updates). My guess is that it's probably deliberately so, because there are always plugin updates, especially since JEP-229, so having an admin monitor that's always on would be spammy and quickly ignored by many admins. Other features like Old Data Monitor do have an admin monitor when they have useful content. Usually because this is something that needs attention (in that case, loss of configuration data, loss of functionality, etc.). If this is added, we need to provide guidelines to explain when you would have the admin monitor, when you would have the badge, and when you would have both. An interesting case is In-Process Script Approval ( |
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 really like this PR. It cleans up the existing tooltip for plugin updates and adds useful additional tooltips (although I'm not entirely sure the node one is useful as-is, given agents on a schedule etc.).
An open question remains about the guidelines for plugin developers on how to use this feature. We should have documentation when to (not) use this ready at the same time we publish this API addition. If we keep the String
type, the docs should also explain it's for short labels only (probably mostly numeric; e.g., 4 of 12
might be OK, 21 available updates
is not). This should be added to Javadoc and/or https://plugins.jenkins.io/design-library/
Otherwise (and assuming a quick re-test confirms the non-HTML tooltip behavior) this looks good 👍
<div tooltip="${m.getUpdateCount() == 1 ? '%updateAvailable(m.getUpdateCount())' : '%updatesAvailable(m.getUpdateCount())'}" class="jenkins-section__item__icon__badge"> | ||
${m.getUpdateCount()} | ||
<j:if test="${m.badge != null}"> | ||
<div tooltip="${m.badgeTooltip}" class="jenkins-section__item__icon__badge"> |
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 is now (once re-merged with master
) a non-HTML tooltip. That seems fine.
Confirmed, non-HTML tooltip and content when merged with |
I'm wondering if there are other places where such badges might be useful. If so it might make sense to create a Badge class that contains the data, tooltip and maybe a severity so the badge can have different colors. Even when not used somewhere else it might help to avoid running some calculations twice (once for the badge and once for the tooltip. |
The agents on a schedule wouldn't be a problem, but the ondemand would show up whenever they have nothing to do and thus disconnect. Maybe restrict the check to agents that use the always online strategy which is the default and most people use I guess. |
For expensive calculations, could be handled by individual Feel free to sketch this out, might be reasonable for future extension (e.g. severity/color), but IMO all that's missing here is related documentation.
Right, something along those lines. Might be simpler to remove this from the PR for now and look into it as followup. Migrating Manage Plugins to this is already pretty nice cleanup, and Manage Old Data is a reasonable new use. |
Badge class takes message, tooltip and severity Do not create badge for NodesLink. It will not work with the agent-maintenance plugin as this configures as well a retention strategy that can't be queried here. To get the reliably working Demand and SimpleScheduled would need some reworking at least. The plugin link badge now changes color when there is an update that fixes a security vulnerability.
I removed the badge for the nodes now, there is no way of reliably determining this information, e.g. when the agent-maintenance enabled for an agent, which is proxying the retentionstrategy |
* @return badge or {@code null} if no badge should be shown. | ||
* @since TODO | ||
*/ | ||
public @CheckForNull Badge getBadge() { |
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.
One drawback of the new Badge
type is that it requires a new core dependency. Previously, the String
based API could be implemented even by plugins with an old core dependency.
I don't think this change must be reverted, but considering simple page navigation shouldn't be expensive anyway, the argument for one call instead of two isn't that strong (expensive computation should be done elsewhere and cached values shown, kind of like available updates).
add info about incompatible changes
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.
LGTM just one wording question in the Javadoc but no blockers, tested locally.
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
/label ready-for-merge This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback. Thanks! |
In multiple comments I kept requesting developer documentation. Could you point me to it?
|
jenkins/core/src/main/java/jenkins/management/Badge.java Lines 33 to 50 in a6d5425
jenkins/core/src/main/java/hudson/model/ManagementLink.java Lines 218 to 223 in a6d5425
jenkins/core/src/main/java/jenkins/management/Badge.java Lines 57 to 66 in a6d5425
|
Thanks, missed it (or forgot in the mean time) 👍 |
* Init * Update core/src/main/resources/lib/layout/task.jelly Co-authored-by: Alexander Brandes <brandes.alexander@web.de> * Remove duplicated class * Update core/src/main/resources/lib/layout/task.jelly Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com> * Add support for badges in menus + manage jenkins page * Update index.jelly * Update ModelObjectWithContextMenu.java * Merge with #6995 * Add tooltip in task links * Add tooltip support to badges * Lint * Escape badge tooltip/text in menus * Use xmlEscape for escaping attributes * Support nulls * Update breadcrumbs.js * Update breadcrumbs.js --------- Co-authored-by: Alexander Brandes <brandes.alexander@web.de> Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com> Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com> Co-authored-by: Tim Jacomb <timjacomb1@gmail.com> Co-authored-by: Alexander Brandes <mc.cache@web.de>
Allow to define a badge icon and a tooltip for all management links.
Adjust PluginsLink to the new method
Add implementations for OldDataMonitor and NodesLink
See JENKINS-69339.
Proposed changelog entries
Proposed 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 upgrade@Restricted
or have@since TODO
Javadoc, as appropriate.@Deprecated(since = "TODO")
or@Deprecated(forRemoval = true, since = "TODO")
if applicable.eval
to ease future introduction of Content-Security-Policy directives (see documentation on jenkins.io).Desired reviewers
@mention
Maintainer checklist
Before the changes are marked as
ready-for-merge
:Proposed changelog entries
are accurate, human-readable, and in the imperative moodupgrade-guide-needed
label is set and there is aProposed upgrade guidelines
section in the PR title. (example)lts-candidate
to be considered (see query).