|
||||||||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group, send email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
The Javadoc could be edited, but I think it is necessary to reconsider the fix, which is just a workaround for missing logic in ConsoleNote.
My understanding of the bug is that we are talking about links within a single Jenkins master. E.g. https://server/job/stuff/1/console should link to https://computer/someslave not http://computer/someslave even if Jenkins “thinks” it is running as http://computer/. Therefore the link must be a complete URL, so hacking Jenkins.rootUrl is necessary (or the Jenkins admin needs to set the root URL to https://computer/ and accept HTTP -> HTTPS redirection as being the lesser evil).
The issue here is that AbstractBuildExecution.run calls ModelHyperlinkNote.encodeTo("/computer/someslave", …), and HyperlinkNote.annotate translates /computer/someslave to http://server/computer/someslave (before the current fix). It does this because it has no other way of determining an absolute URI: you could be running Jenkins with a web app context path like http://computer/ci/, or you could be running Jenkins behind a reverse proxy that maps http://localhost:8080/ to http://mycorp.com/ci/, etc., so /computer/someslave cannot be guaranteed to resolve to anything useful. Nor can //computer/someslave, so network-path references are irrelevant.
The best fix (IMO) would be to produce a relative URI, ../../../computer/someslave in this case, which will not only preserve scheme but would work correctly even in the face of an incorrect Jenkins.rootUrl setting. The difficulty is that HyperlinkNote.annotate now needs to take its Object context and determine its URL relative to the context root; and there seems to be no standard interface for this. For example, Run.getUrl does not implement any method. Perhaps such an interface could be introduced retroactively, in which case contexts assignable to this interface could result in relative URIs (with absolute URLs being used as a fallback).