Overhaul search with a Command Palette

[janfaracik]

This PR introduces the Command Palette concept to Jenkins, first discussed back in the day in the November 2021 UX SIG meeting. You've probably used something similar if you've used VS Code, Jenkins.io, GitHub, Spotify etc. They're handy overlays that allow you to quickly use your keyboard to navigate, be that searching for different pages or finding functions in menus.

This is an early implementation and as such doesn't have all the features I want it to have, such as grouped results, icons and richer details for results, all aimed at making the search experience in Jenkins easier to use. I'd also like for plugin developers to eventually be able to integrate with the Command Palette so they can provide their own rich results/actions, for example being able to change theme from the palette.

Testing done

• Clicking the search button shows the Command Palette
• CMD + K shows the Command Palette
• Searching for terms brings up identical results to the previous search bar

Proposed changelog entries

• Add Command Palette as replacement for search bar

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

Maintainer checklist

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

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

[github-actions]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[github-actions]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[timja]

Can you create a draft PR to the lucene plugin showing that compatibility is maintained?

[janfaracik]

Can you create a draft PR to the lucene plugin showing that compatibility is maintained?

Done - jenkinsci/lucene-search-plugin#69

[github-actions]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[mawinter69]

I created JENKINS-73564 to track removal of YUI from the searchbox which this PR accomplishes

[timja]

@daniel-beck are you able to take another look please?

[daniel-beck]

Sorry for the delay here. With Java EE over, I plan to look at this in the next few days.

[judovana]

hi!

Just pelase keep the old search around. There is only few plugins overriding it, but those have usually purpose. The old search can be done pretty powerful. The command palette and full search are two different things. With full search, you can search in job names, in build-ids, in artifacts (similar to full searches in IDE's projecs). With command pallete you should search in "waht this tool do" - manage nodes, manage jobs. manage plugins.... Those two things have small intersections, but otherwise should be kept separated.

My irrelevant $0.002

[daniel-beck]

@judovana

Just pelase keep the old search around

Could you clarify whether the current state, which retains the /search/ URL and allows navigating there, does that? Is the problem that out of the box, there is no longer an entrypoint to get there? The proposed change to lucene-search basically adds a link there.

---

(IMO there are some limitations to how "search" behaves at the moment which makes it pretty awkward. E.g., it only supports a single Search subclass to handle the URL for a given SearchableModelObject. Having nested-view, lucene-search, and search-all-results-plugin installed at the same time isn't a good search experience, one of them simply wins. The extension point seems intended to override the search experience for a single specific SearchableModelObject rather than having multiple plugins contribute to search, globally.

This is another indicator that the current "search" really was intended as just (or perhaps primarily) a launcher.

jenkins/core/src/main/java/hudson/search/package-info.java

Lines 25 to 28 in 2d2adef

	/**
	* <a href="https://qsapp.com/">QuickSilver</a>-like search/jump capability for better navigation around Jenkins.
	*/
	package hudson.search;

is kinda authoritative, originally added in 2007.)

(FWIW I started looking into this again, noticing other implementations, e.g., nested-view, which led me to the detour #9737.)