Add badges to build page

[strangelookingnerd]

Add badge actions to the build page.

Following a discussion with @janfaracik and @timja in jenkinsci/badge-plugin#263 I propose to add badges (provided by BadgeActions) to the build page. In my opinion it only makes sence to have the information of the badges displayed here as well rather then having it only in the build history.

Full disclaimer: I am far from being a UI/UX expert, but want to push this topic forward. So any feedback is highly welcome!

Testing done

See before and after screenshots:

Before

After

Proposed changelog entries

• Add badges to build page

Proposed changelog category

/label rfe,web-ui

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@jenkinsci/sig-ux @jenkinsci/core-pr-reviewers

Before the changes are marked as ready-for-merge:

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[daniel-beck]

This looks weird with the usual (everywhere else except badge and groovy-buildstep) badges that are just an icon.

Plus the tooltip is wrong for this one in core, the sidepanel includes the cause:

(forgot to set it or similar?)

---

IMO: If an action should appear on the project page, there should be such an action. Reusing badges just for convenience in badge plugin seems too focused on the existing implementation.

[strangelookingnerd]

This looks weird with the usual (everywhere else except badge and groovy-buildstep) badges that are just an icon.

Can't really argue with that. Maybe adding some sort of container would help to make the icons not look so out of place.

IMO: If an action should appear on the project page, there should be such an action. Reusing badges just for convenience in badge plugin seems too focused on the existing implementation.

The idea is to mirror the information from the build history here, hence a new action would defeat that purpose. It's less about convenience but consistency. Or is there any reason to not have that information here?

[strangelookingnerd]

Plus the tooltip is wrong for this one in core, the sidepanel includes the cause:

Fixed in 73d4080

[strangelookingnerd]

Other approaches I found to be a little more appealing:

Badges to the right

Badges in a container

[daniel-beck]

The idea is to mirror the information from the build history here, hence a new action would defeat that purpose.

I disagree with the idea, that's the point of my feedback. If the information should appear on this page as well, then it should be such an action added to the build. For example https://plugins.jenkins.io/buildtriggerbadge/ only makes sense in the widget, because causes are already shown on the main build page.

Badge plugin could do this, and it's not clear to me why it's not being changed to do this. What do we gain from this change to core behavior?

Other approaches I found to be a little more appealing

These look a lot nicer. To the right of the build number/name might also work.

[strangelookingnerd]

The idea is to mirror the information from the build history here, hence a new action would defeat that purpose.

I disagree with the idea, that's the point of my feedback. If the information should appear on this page as well, then it should be such an action added to the build. For example https://plugins.jenkins.io/buildtriggerbadge/ only makes sense in the widget, because causes are already shown on the main build page.

Understood. I also kind of disagree with your feedback, but you do raise a fair point.
Another approach to this could be to add the build history widget to every build page. Any thoughts on that?

Badge plugin could do this, and it's not clear to me why it's not being changed to do this. What do we gain from this change to core behavior?

Like how? The only extension point I can think of here is to have a summary.jelly that displays all badge actions added to the build by the badge plugin (or even all of them).

Other approaches I found to be a little more appealing

These look a lot nicer. To the right of the build number/name might also work.

I tried that but was not really happy with the result, so I scratched it.

[daniel-beck]

Like how? The only extension point I can think of here is to have a summary.jelly that displays all badge actions added to the build by the badge plugin (or even all of them).

Looking at the plugin, BadgeSummaryAction and AddSummaryStep already exist, so this request is even less clear to me now. If I want something to show on the main page, that's how I do it already now, or not?

[henriduflot]

Currently, you proposed to use Jenkins addSummary method to display badge on build page:

addSummary text: "temurin-21", style: 'color: var(--accent-color)', cssClass: 'badge-text--background'
addSummary text: "redeploy", style: 'color: var(--text-color-secondary)', cssClass: 'badge-text--background'
addSummary text: "tests failed", style: 'color: var(--error-color)', cssClass: 'badge-text--background'
addSummary text: "security issues", style: 'color: var(--warning-color)', cssClass: 'badge-text--background'

The problem with this approach is:

1. These summaries appear scattered throughout the build page as other plugins add their own summaries
2. They display line by line, potentially pushing important information to the bottom of the page
3. It requires using both addBadge and addSummary methods, which is not practical

We need a more efficient way to display badges that:

1. Shows all badges in a single section at the top of the build page
2. Displays badges on the same line
3. Consolidates the badge functionality into a single method call
4. Ensures important build information is immediately visible

This would improve visibility of critical build information and create a more consistent user experience.

[daniel-beck]

These summaries appear scattered throughout the build page as other plugins add their own summaries
They display line by line, potentially pushing important information to the bottom of the page

These are implementation choices and could easily be done differently by the plugin.

It requires using both addBadge and addSummary methods, which is not practical

Others may see this as allowing fine-grained control of what shows where, and this change would result in a confusing API ("badges" are actually "badge + summary" and summary is just summary).

[strangelookingnerd]

These summaries appear scattered throughout the build page as other plugins add their own summaries
They display line by line, potentially pushing important information to the bottom of the page

These are implementation choices and could easily be done differently by the plugin.

I don't think this is the case as the layout is controlled by the enclosing container which resides in core.

It requires using both addBadge and addSummary methods, which is not practical

Others may see this as allowing fine-grained control of what shows where, and this change would result in a confusing API ("badges" are actually "badge + summary" and summary is just summary).

Not sure if I fully agree on that. I think it's more about displaying badges not only in the build history widget but also on the build summary page. Similar to the build status, number or execution time.

[daniel-beck]

I don't think this is the case as the layout is controlled by the enclosing container which resides in core.

There is no reason https://github.com/jenkinsci/badge-plugin/blob/d6672d7cd54f53170d24d7dca4181feb73b28218/src/main/java/com/jenkinsci/plugins/badge/dsl/CreateSummaryStep.java#L128 needs to add a new BadgeSummaryAction every time it is invoked. Redefine the BadgeSummaryAction as holding a list of summaries, and add one to the list if there's already an Action of that type. CauseAction in core has been doing something similar since 2009.