Allow customization of Job icons

[strangelookingnerd]

In a discussion with @jonesbusy in jenkinsci/custom-folder-icon-plugin#387 I stumbled upon custom-job-icon-plugin which by now has become deprecated / out-dated but brought up the interesting idea of being able to change the default icon of a Job from the BallColor to something else similar as custom-folder-icon-plugin already does it for AbstractFolder.

Since I really liked the idea and already have a use case myself I wanted to bring this to the core to lay the foundation.

This PR aims to introduce configurable icons for jobs and potentially also other types of items.

The first step is to add a new column to show the icon, similar to the status or weather icons. By default the column uses the icon and description describing the "type" of an item.

Screenshot:

The second step is to add some sort of configuration to Job that allows customization (tbd. / work in progress).

Full disclaimer, I am aware that this draft is still a little rough on the edges how ever to see if this goes anywhere I'd be grateful for some feedback.

Testing done

Only manual testing so far, tests to follow in case we want to follow up on this draft.

Proposed changelog entries

tbd.

Proposed upgrade guidelines

N/A

Submitter checklist

Beta Give feedback

1. The Jira issue, if it exists, is well-described.
2. 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.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. 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).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

N/A

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

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. 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).
6. 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).

[jonesbusy]

Thanks! I really like the idea!

[daniel-beck]

The complication here is that this is where jobs show their status – hence the "S" in the column title. While it seems useful to have a "type" indicator for jobs (e.g., using the icons from the "New Item" dialog) that extends beyond Folders (an item type with no natural status, at least not before ComputedFolder), and have that be customizable, this removes the build status information from view.

For that reason I am against this proposal as implemented. It seems to me that, to properly support this in a way that makes sense, we'd need another column as job type indicator first (with corresponding adaptation of the Folders plugin behavior IMO).

[strangelookingnerd]

The complication here is that this is where jobs show their status – hence the "S" in the column title. While it seems useful to have a "type" indicator for jobs (e.g., using the icons from the "New Item" dialog) that extends beyond Folders (an item type with no natural status, at least not before ComputedFolder), and have that be customizable, this removes the build status information from view.

For that reason I am against this proposal as implemented. It seems to me that, to properly support this in a way that makes sense, we'd need another column as job type indicator first (with corresponding adaptation of the Folders plugin behavior IMO).

I mean, we could have Item or AbstractItem or TopLevelItem (?) have a icon field and this way also enable all sub-classes to inherit the feature. This would make large portions of the Folder implementation around icons obsolete I guess. The default implementation could simply use the icon from the "New Item" dialog and stand for the "type" as you already mentioned.

One thing I kind of disagree with is calling it "type" because that again - as the status - has an implication to it.
For example there is https://plugins.jenkins.io/custom-folder-icon/#plugin-content-build-status-folder-icon - a build status for Folders. Simply calling it "icon" would be sufficient in my opinion.

[daniel-beck]

For example there is https://plugins.jenkins.io/custom-folder-icon/#plugin-content-build-status-folder-icon - a build status for Folders. Simply calling it "icon" would be sufficient in my opinion.

Right, the same problem applies to current organization folders, like e.g. on https://ci.jenkins.io/ that use the "Status" column for the organization icon. If we end up splitting the current status (except Folder with fixed icon) column into a "always status" and "always icon" column, that involves looking into how to adapt Folders accordingly.

[strangelookingnerd]

So the first step would be to add a new column IconColumn in core views similar to StatusColumn.
Now the question is, what should be displayed there and where does it come from?

As said before, I'd imagine adding a icon field to AbstractItem. It could be based on org.jenkins.ui.icon.Icon and provided by an interface so other comsumers could opt-in e.g. SCMNavigator
With a proper default there would be no need to change anything on the implementing classes if they don't want to.

WDYT?

[daniel-beck]

@strangelookingnerd That would be my suggestion, with the default being the item type icon from the New Item dialog. Obviously, that's just me and others may well see this differently (including future me once I've seen a prototype 😬 ).

[strangelookingnerd]

I am sure that there will be some back an forth but I will try and look into creating a prototype and we see where that brings us. Setting this back to Draft for the time being.

[github-actions]

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

[strangelookingnerd]

@daniel-beck I updated the PR and implemented the first step towards a polished solution. Please let me know what you think.

I also had a go at adding a configuration for items in order to allow customization of icons that also enable providers for the icons. I may need a little more time to contemplate how to best solve it.