I could pin point the problem we have here. Let me try to explain.
The icon.jelly is trying to find the source of the image using Functions#tryGetIconPath(String, JellyContext) method. That method then uses Functions#tryGetIcon(String) method. This method is trying to find the icon with the IconSet#getIconByClassSpec(String). Until this point, the icon was referred by gitlab-commit (or any other). The getIconByClassSpec method looks at the map called iconsByClassSpec, which is not populated when the icons are added into the IconSet but when the icons are requested (in this method). As the map doesn't contain the gitlab-commit, it tries to look into the iconsByCSSSelector map, which is populated when the icons are added into the IconSet.
The problem is, when the icons are added, they are suffixed by the icon size class (icon-md, icon-sm, etc.). The same icon is added 4 times, to have all the size. This is coming from the time we had png files, and one for each size.
However, when we are looking at the icon the first time, we are looking for gitlab-commit, without any CSS class for the size. So the icon is not found in the CSS class map. At this point, no icon is found and the code is adding the NO_ICON into the iconsByClassSpec map and null is returned by the getIconByClassSpec(String) method.
Back to Functions#tryGetIcon, the null value makes the code goes again into the IconSet#getIconByClassSpec(String) but, this time, two modifications are made on the String used to referenced the icon: it's "normalized" using IconSet#toNormalizedIconNameClass(String) and is suffixed by icon-md. The toNormalizedIconNameClass using Icon#toNormalizedIconNameClass(String) method, which prefixed the icon name by icon- if it was not.
When the IconSet#getIconByClassSpec(String) will look for the icon, it won't find the new reference icon-gitlab-commit icon-md into the iconsByClassSpec map (because it was never requested), so it will look for it into the CSS class map. However, when icons were added, the CSS classes where not prefixed with icon-, so again, we store the NO_ICON reference into the map and we return null.
From here, there are two things I can see we need to do:
1. we use the Icon#toNormalizedClassName(String) method when we create a new Icon for the classSpec attribute
2. in order to not have to change the plugins, we need to make sure that the iconClassSpec parameter of the IconSet#getIconByClassSpec(String) method is transformed to be "normalized".
The problems:
1. Some icons are looked at by URL, which means that the iconClassSpec is something like /plugin/credentials/xxx, and this is prefixed by icon-, which is not found and stored like that into the iconsClassSpec map with a reference to the NO_ICON. Later the code is looking that the icon with the URL map, and is found. So the icons are served correctly, but this is suboptimal.
2. we have a map which have a correspondance to icon-gitlab-commit with a reference to the NO_ICON, so the code is always taking the long road to find the icon. In my tests, I saw that it was already the case for the icon-folder icon
So, the "solution" I have is basically a disaster in the making, growing the map with invalid reference to the same NO_ICON, forcing the icon lookup mechanism to use more memory (by populating the map) and taking more lines of code to find the icons we are looking for.
When the GitlabSCMSource and GitlabSCMNavigator retrieveActions methods are triggered, a GitlabLink action (IconSpec implementation) are added to the relevant output of the project.
Those GitlabLink objects have a gitlab-X reference, which is used in the actions.jelly of core to resolve the icon to use (through a task.jelly which will be resolved as a icon.jelly).
During the initialization of the plugin, icons are added into the IconSet "bank" with the id "gitlab-X".
This provides the controller with a way to resolve "gitlab-X" -> URL to be able to fetch the image.
The IconSet has:
(not mentioning the core icons)
When adding a Icon into the IconSet, the method addIcon adds it to the CSSSelector and URL resolver, but not to the ClassSpec. However, when the instance is completely initialized, we can run
and see that the gitlab-X are added but with the URL _.
The actions.jelly tries to resolve the iconClassName using the IconSet#getIconByClassSpec only and find a IconSet#NO_ICON placeholder. In the end, the icons are not shown.
However, and this shouldn't be the fix, but adding the icon- prefix to the icons class spec, on the GitlabLink objects and on the iconClassName of both GitlabSCMSource and GitlabSCMNavigator descriptors fix the problem, for new projects.