[JENKINS-32178] Fix broken links to branches from custom views

[mjdetullio]

JENKINS-32178

[mjdetullio]

ping @stephenc @jglick

[stephenc]

Hmmm I need to think about this one

[mjdetullio]

Custom views are essentially broken, solely due to the override. Any old links referencing jenkins/my-multi-branch-project/branch/feature-abc/ will still work since getBranch(String) is not being removed.

[stephenc]

wouldn't a better option be to add a hidden action called job. As views delegate to the folder for actions that would resolve the job action and then that can just be a StaplerProxy for the corresponding call to getBranch

[mjdetullio]

I took another crack at it using an action as you suggested, completely replacing the previous implementation. The action is completely hidden as you suggest and will work with any override for MultiBranchProject#getUrlChildPrefix() by delegating to MultiBranchProject#getItem(String)

The only problem I could find with this is shown in this screenshot, where an extra blank breadcrumb is added to the top of the page.

[mjdetullio]

Also I looked into using StaplerProxy, but by the time the action is handled by Stapler, branch is no longer part of the remaining URL. StaplerProxy can't delegate individual methods to another object, only the remaining part of the URL to another object, so I wasn't able to use it. A normal public method sufficed.

[stephenc]

I think that is fixable. At the very least we could turn it into a temporary redirect to the correct URL since we just want to fix users browsing by clicking links so they should not have links to sub-elements. But I think there is another way that removes the breadcrumb also

[mjdetullio]

Well, the effect of the extra breadcrumb is visual only. It's not clickable and does not generate children. The children are already correctly listed by the view breadcrumb.

I looked at the breadcrumbBar.jelly file and it does not appear there is a way to exclude the entry. h#isModel will always return true for actions and I'm not aware of any way to negate the second comparison with the ancestor URL. https://github.com/jenkinsci/jenkins/blob/jenkins-2.1/core/src/main/resources/lib/layout/breadcrumbBar.jelly#L60

I don't think an HTTP redirect for the user is the correct approach. It could make things unnecessarily complex or broken for the JSON/XML web APIs.

[jglick]

Why not just get rid of the custom URL prefix override? Would fix everything and the only patch is deleting a few lines of code.

[mjdetullio]

That was the original patch but there was some debate from @stephenc

[jglick]

I see. (Well, I do not see, since I guess you force-pushed a different commit, but I can imagine.) So @stephenc why do we care about preserving the custom URL prefix? Seems like it is much more of a hassle than it is worth.

[mjdetullio]

Correct, I did force push over it and seemed to have lost the commit to the sands of time. The original change was removing the prefix override and deprecating MultiBranchProject#getBranch().

[stephenc]

Because I would prefer to keep the semantic meaning. @jglick Ping me on Monday and we can discuss more

[jglick]

In fact the current URL pattern breaks this too, which is causing me problems in jenkinsci/workflow-cps-plugin#12.

Note that OrganizationFolder just uses job/. I think after #8 we should just say that all ComputedFolders should behave as much like Folders as possible.

[jglick]

cf. jenkinsci/workflow-step-api-plugin#3

[jglick]

Could hardcode /(?:job|branch)/ as a regexp separator for that case but seems even uglier than it already is.

[stephenc]

@jglick ok you won me over... reluctantly, but I'll accept us moving to job (though it would be much better if everyone could just move to item

[mjdetullio]

Updated PR back to original change

[jglick]

👍