[JENKINS-75727] Distinguish between primary and secondary actions in the header

[jtnord]

This PR distinguishes between primary and secondary Actions for the header.

Primary actions are always shown, and secondary actions are by default in the Hamburger menu.
When the current page is the page for the secondary action (or a parent thereof) the action is put in the main header action list and not in the hamburger menu.

This solves (partially) JENKINS-75727 in that whilst the collapsed icon is still collapsed when on its page the dropdown would be shown.

Screenshots

in the root of Jenkins

in the system identity page (the action is now in the main header)

See JENKINS-75727.

Testing done

Manual testing

• without any extra plugins (hamburger does not appear)
• adding job-config-history
  ** check the action shows in the hamburger when on the root page
  ** check the action shows in the top panel when on the job-config-history page

Proposed changelog entries

• Place secondary actions in the collapsing menu instead of displaying them based on screen width.

Proposed changelog category

/label rfe

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

@mention

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).

[jtnord]

tbh this all seems a bit wrong.

We have a generic taglib, but this rendering is specific to the JenkinsHeader

Open to better suggestions.

[jtnord]

extracted as the only remaining code from actions-overflow.js

[jtnord]

I am not sure why we consider it is only important to do this for the User action and not any action with a JumpList.

At the same time, this comment seems incorrect. I can use touch to get the dropdown menu on windows 11 with a touch screen using a long touch and I can navigate directly using a quick touch. (My laptop is not (generally) detected as a touch device :-) )

Anyway, this was existing code I have just relocated and I am not intending to unpick this in this PR (or even in a follow-up).

[jtnord]

Additionally this seems to behave no differently on an android phone on weekly.ci.jenkins.io 🤷

[jtnord]

renamed to actions-touch.js and all the collapsing removed

[jtnord]

NB: existing code, simpleName is liable to collisions.

[Copilot]

Pull Request Overview

This PR distinguishes between primary and secondary header actions by separating their rendering logic and behavior. Key changes include:

• Introducing updateActionsForTouch in the header to disable UserAction href on touch devices.
• Splitting the rendering of header actions into primary and secondary (hamburger menu) actions via updated Jelly templates.
• Updating Java interfaces and classes with an isPrimaryAction method to support the new behavior.

Reviewed Changes

Copilot reviewed 11 out of 12 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/main/js/components/header/index.js	Added updateActionsForTouch and removed computeActions from computeOverflow.
src/main/js/components/header/actions-touch.js	New module to control touch-specific behavior for header actions.
src/main/js/components/header/actions-overflow.js	Removed overflow logic now replaced by updated action rendering.
core/src/main/resources/lib/layout/header/*.jelly	Updated Jelly templates to differentiate between primary and secondary actions.
core/src/main/java/jenkins/views/Header.java, etc.	Updated Java classes to override isPrimaryAction and adjust documentation.

[MarkEWaite]

Two comments on Javadoc. Testing looks good to me. Will continue later today

[MarkEWaite]

Passed my interactive testing. Works well with the plugins that I tested, including purge build queue and priority sorter.

[jtnord]

@MarkEWaite this solves JENKINS-75727 (a bug) by never collapsing an action for the current page, thus allowing its menu to be shown. I think this qualifies for the bug label even if it doesn't show the menu when the action is not current?

[MarkEWaite]

@MarkEWaite this solves JENKINS-75727 (a bug) by never collapsing an action for the current page, thus allowing its menu to be shown. I think this qualifies for the bug label even if it doesn't show the menu when the action is not current?

You are right that it can be classified as a bug in addition to being an enhancement. I was worried that applying both the rfe and the bug label may attempt to create two entries in the Jenkins weekly changelog. If that happens, the changelog curator (@kmartens27) will probably delete one of the two. I was trying to avoid the risk that one of the two would need to be deleted and thought that readers of the Jenkins weekly changelog would be more likely to read the description of the change as a bug than as an enhancement.

No problem if it is labeled as both bug and rfe. @kmartens27 will assure that the weekly changelog makes sense in any case.

[MarkEWaite]

@janfaracik I'd really like your review and approval of this pull request. I think this is the right direction for the collapsing menu in the header so that components specifically declare that they want to always appear in the header or appear in the collapsing menu.

[MarkEWaite]

@scherler I'd like your review and approval of this pull request as well. I very much want to include it in the June 24, 2025 release of Jenkins 2.516 so that we can include it in the LTS baseline for the July 23, 2025 LTS release.

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

[A1exKH]

LGTM.

[janfaracik]

Apologies I've been on leave -

Haven't had a chance to try this but idea/code wise looks fine to me as is. It'd be good to have some guidance written up as to what makes a good primary/secondary action for the header, and when a plugin should/should not contribute to it.

[jtnord]

It'd be good to have some guidance written up as to what makes a good primary/secondary action for the header, and when a plugin should/should not contribute to it.

As this is ready for merge (and CloudBees' has already integrated this into our build) selfishly I would prefer to do this in a separate PR to avoid merge conflicts.

[janfaracik]

It'd be good to have some guidance written up as to what makes a good primary/secondary action for the header, and when a plugin should/should not contribute to it.

As this is ready for merge (and CloudBees' has already integrated this into our build) selfishly I would prefer to do this in a separate PR to avoid merge conflicts.

Yeah no worries/rush at all - I've opened jenkinsci/design-library-plugin#428 that can be used as a spot for that guidance.

[jtnord]

It'd be good to have some guidance written up as to what makes a good primary/secondary action for the header, and when a plugin should/should not contribute to it.

As this is ready for merge (and CloudBees' has already integrated this into our build) selfishly I would prefer to do this in a separate PR to avoid merge conflicts.

Yeah no worries/rush at all - I've opened jenkinsci/design-library-plugin#428 that can be used as a spot for that guidance.

Ahh I was half way through doing this in javadoc :)

❯ git diff
diff --git a/core/src/main/java/hudson/model/RootAction.java b/core/src/main/java/hudson/model/RootAction.java
index b13e69f160..5565593d79 100644
--- a/core/src/main/java/hudson/model/RootAction.java
+++ b/core/src/main/java/hudson/model/RootAction.java
@@ -54,7 +54,10 @@ public interface RootAction extends Action, ExtensionPoint {
     /**
      * Identifies if the action as a primary action.
      * Primary actions may be handled differently in the UI (for existence by always showing on the header rather than in an actions dropdown).
-     * In almost all cases this should return {@code false} which is the default
+     * In almost all cases this should return {@code false} which is the default.
+     * Examples of a Primary action would be where actions would be used regularly or they would need to be prominent to convey some status.
+     * A concrete example would be an action that provides for Help with a submenu containing various different links would be a prime candidate for this to return true.
+     * If your action has the possibility of a {@link #getBadge() badge} then this is another indicator that the action should be a primary action (or otherwise refactored!)
      * @return {@code true} iff this action should be considered primary.
      */
     default boolean isPrimaryAction() {