-
Task
-
Resolution: Fixed
-
Minor
It is the follow-up to our discussion with recena and jglick.
The current Item categorization uses JENKINS_URL/categories endpoint to provide the list of categories.
It causes several concerns:
- Categories apply to items only, but the "/categories" endpoint does not mention it in paths. Once we want to implement slave categories, it may become a problem
- The endpoint may conflict with existing closed-source plugins. E.g. I had the Categorization plugin at one of my previous companies, which used the similar endpoint. Update to 2.0 will cause regressions in such plugins
- The implementation is not pluggable. E.g. Views and Items cannot filter the categories somehow
Proposed solution:
- Ship categories via VIEW_URL/itemCategories
- Allow overriding of the method in views. Just for the future pluggability
- links to
[JENKINS-33972] Item Categories should not be shipped from /categories
Categories apply to items only, but the "/categories" endpoint does not mention it in paths.
This endpoint is not valid, the right endpoint is: JENKINS_ROOT/PATH_VIEW/categories where PATH_VIEW can be:
- empty: JENKINS_ROOT/categories
- or for example: JENKINS_ROOT/view/custom/categories
The meaning is Please, give me the item categories and its items availables in this view.
The endpoint may conflict with existing closed-source plugins. E.g. I had the Categorization plugin at one of my previous companies, which used the similar endpoint. Update to 2.0 will cause regressions in such plugins
Is this really an argument? As contributor of Jenkins core I have to thing about possible proprietary developments. This is crazy! Why something like itemCategories is a valid option?
The implementation is not pluggable. E.g. Views and Items cannot filter the categories somehow
This is a new requirement we can implement in the future. By the way, Items are being filtered.
> empty: JENKINS_ROOT/categories
So in such case it overlaps with the corner-case I've provided
> Is this really an argument? As contributor of Jenkins core I have to thing about possible proprietary developments. This is crazy!
You are not supposed to think about them. That's why we have Jenkins 2.0 beta testing, because it allows users to notify us about such issues. It does not mean that we must fix such issues, but at least it worths some discussion
Closed-source plugins are not an argument to me. I'm not even sure open-source plugins would be a major argument to impede core development, depending on exactly what the problem is. They would just be fixed. Otherwise, no detaching JUnit plugin from core in 1.577, or ever.
However, Oleg does have a point with the confusion regarding what the categories are for. So a rename to itemCategories to support e.g. viewCategories besides it, seems straightforward enough. FWIW I was a big proponent for generic categorization from the beginning, Jenkins users typically have more view types than item types.
> Closed-source plugins are not an argument to me. I'm not even sure open-source plugins would be a major argument to impede core development, depending on exactly what the problem is. They would just be fixed.
IMHO it does not well comply with the "this guy is fully compatible, no reason not to upgrade" statement we declare for 2.0. I'm OK if we don't fix in this case, but there maybe corner cases. Maybe we should explicitly recommend testing before upgrading.
oleg_nenashev By the way, the renaming involves to send a new PR to cloudbees-folder-plugin ref.
jglick Do you agree with the change proposed? Remember that this change involves to change this again.
Yes go ahead and change categories to itemCategories. I was holding off on a cloudbees-folder release until you did so, so that I can make the matching change.
I disagree because: