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

Preview 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

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

[daniel-beck]

@strangelookingnerd Thanks, I'll try to look at this soon!

[daniel-beck]

👍 This looks pretty reasonable to me:

Folders plugin will need to be adapted (we'll need guidelines what to show in the status column now if there's no "Status").

I'm wondering about the "I" for "Icon" column title, would have expected "T" / "Type" or similar instead, even though custom icons are the motivation for the change.

[strangelookingnerd]

Folders plugin will need to be adapted (we'll need guidelines what to show in the status column now if there's no "Status").

Yes, that is something that I could look into.
Right now I think it would be best to not display anything in case there is nothing that qualifies as „status“. So for Folders one could think about adopting my implementation of a Build Status Folder Icon. For Multibranch Pipelines there’s the result of the repository scan and so on.

I'm wondering about the "I" for "Icon" column title, would have expected "T" / "Type" or similar instead, even though custom icons are the motivation for the change.

While I do agree that the „I“ looks odd - a „T“ would not make it better IMHO. And also, as you already hinted, once there are custom icons involved „Type“ is as misleading as „Status“ is right now. So what about no header text? Would not be the worst idea to be honest.

[strangelookingnerd]

I had a go at making the icon and status to each have their respective icons including fallbacks in the relevant views. This looks a little something like this:

Things to notice:

• Folder uses the default icon and has no status
• Folder with Custom Icon is using a custom icon and has no status because there is no job in it
• Folder with Jobs uses the default icon and contains a build job. A very minor patch in the Folders plugin based on Build Status Folder Icon provides the combined build status of the jobs within as status. Looks pretty neat if you ask me 😄
• Freestyle project uses the default icon and status Not built. But since it now has an icon to display I thought it would be nice to have it included in the overview (previously there was no status or icon at all):
  
• Freestyle project with build uses the default icon and status Success. The overview reflects that as before:
  
• Multibranch Pipeline uses the default icon and has no status. A minor change however could either provide the Scan Multibranch Pipeline Log result or have a similar implementation as shown in Folder with Jobs
• Organization Folder uses the default icon and has no status. A minor change however could either provide the Scan Organization Folder Log result or have a similar implementation as shown in Folder with Jobs

I am still not sure what to do with the column header. I tried to remove it which looks a little off and removes the possibility to sort the column - which may be useful if you want to sort by "type" of items.

Adding a non-breaking space (&nbsp) would restore a way to sort, however the sorting is somewhat "broken" (notice the Folder with Custom Icon being at the bottom for some reason):