Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[JENKINS-43581] - Create new custom tool button should be on top #2926
Proposed changelog entries
Adds button, for adding new entries, on top of a repeatable form (issue 43581)
The change impacts all
repeatable.jelly usages, and IMHO it may cause some UX issues in cases when the list is short.
I would advice to add a new
attrs parameter, which enables the button on the top. And then apply it to the long layouts like tools.
I have reviewed it yesterday. The most of the change looks good, and thanks for adding tests for it.
I have only minor comments regarding the license headers and the CSS file
I suppose it fixes the issue as reported by introducing yet more buttons. I feel sorry for the person who wants their stuff to appear in the middle of the list.
Besides that obvious limitation, I'm really not sure about this. As I wrote above,
And all other lists don't get this. I'm pretty sure the corresponding request for build steps is even older than this. In the case of build steps, we might be saying that it's not a good idea to have so many different ones to begin with. But personally, I'd say the same for lists of tool installations.
Not strongly opposed, but I don't think this is a good solution either.
I agree though I rather see it as a follow-up ticket. Testing UX on a single control LGTM. More feedback from @jenkinsci/code-reviewers would be definitely useful
I won't commit to implement anything, because I cannot guarantee that I deliver on this commitment. And I do not get why this particular PR is being blocked by that @daniel-beck. I have recently received a provate ping from @Ykus about this proposal, but I cannot help much in this case. And I do not want to push a contributor to rework many Jenkins components just to make his limited-scope UI improvement landed.
I do not think the minor usability improvement here outweighs the resulting inconsistency between similar UI controls, making this a (slightly) net negative change. Hence my previous comment.
The road forward is clear IMO: Not do this, or apply it consistently.
Again, I'm not specifically blocking this if you feel strongly, but it doesn't look to me that many others are interested in seeing this land based on limited feedback here.
I am merging it on my own responsibility since nobody else blocks the pull request. Although it is a "minor improvement" for API users, it is a significant UX improvement for Jenkins admins who have to define many tool installations. The change is well covered by tests. Since we have much bigger barely-justified changes like XML 1.1 merged, I consider it is as a judgment call. And in this case I decide to merge this contribution from a community member instead of blocking it indefinitely.