• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None

      Some links (e.g. in console output lnks "Building remotely on slaveXYZ") don't preserve protocol and have hardcoded HTTP even if the page is opened via HTTPS. This can be considered as a security risk (e.g. user doesn't notice change of the protocol and later on can open another console output with sensitive data and the data would be sent over unsecure HTTP in this case)

          [JENKINS-16368] Hardcoded protocol in some links

          vjuranek added a comment -

          vjuranek added a comment - Fixed in https://github.com/jenkinsci/jenkins/commit/460e508155187918e8c0f4fd0bb66a99cfe78527

          kutzi added a comment -

          Might also be worth thinking about using network-path references http://stackoverflow.com/questions/3583103/network-path-reference-uri-scheme-relative-urls

          kutzi added a comment - Might also be worth thinking about using network-path references http://stackoverflow.com/questions/3583103/network-path-reference-uri-scheme-relative-urls

          Jesse Glick added a comment -

          @kutzi I think you mean just simple absolute URIs like /computer/slaveXYZ; a network-path reference would be to a different server using the same protocol (//elsewhere.net/something), which is not needed for anything in Jenkins AFAIK.

          Jesse Glick added a comment - @kutzi I think you mean just simple absolute URIs like /computer/slaveXYZ ; a network-path reference would be to a different server using the same protocol ( //elsewhere.net/something ), which is not needed for anything in Jenkins AFAIK.

          kutzi added a comment - - edited

          Actually, I was thinking about network-path reference as this bug - as I understand it - is that in some places Jenkins#getRootUrl() is used to construct intra-Jenkins links. Indeed, using absolute URIs in this case would be the even better solution.

          I find it quite strange that the value of getRootUrl doesn't always return the same - configured - value, but - based on the 'current' request - something different. But that was already so before this fix, so it doesn't actually worsen the situation.

          kutzi added a comment - - edited Actually, I was thinking about network-path reference as this bug - as I understand it - is that in some places Jenkins#getRootUrl() is used to construct intra-Jenkins links. Indeed, using absolute URIs in this case would be the even better solution. I find it quite strange that the value of getRootUrl doesn't always return the same - configured - value, but - based on the 'current' request - something different. But that was already so before this fix, so it doesn't actually worsen the situation.

          kutzi added a comment -

          Looking at it again, it actually does worsen the situation, as previously I was either getting the configured value or getRootUrlFromRequest() - which is also (kind of) mentioned in the Javadoc.
          Now I have 3 different return values, based on the context.

          kutzi added a comment - Looking at it again, it actually does worsen the situation, as previously I was either getting the configured value or getRootUrlFromRequest() - which is also (kind of) mentioned in the Javadoc. Now I have 3 different return values, based on the context.

          Jesse Glick added a comment -

          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).

          Jesse Glick added a comment - 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).

          kutzi added a comment - - edited

          We could have a new method in Jenkins which returns the rootUrl without protocol, so ModelHyperlinkNote could use absolute URIs, like you mentioned.
          Or am I misunderstanding the issue?
          Forget it. I think you already answered this with the proxy example.

          kutzi added a comment - - edited We could have a new method in Jenkins which returns the rootUrl without protocol, so ModelHyperlinkNote could use absolute URIs, like you mentioned. Or am I misunderstanding the issue? Forget it. I think you already answered this with the proxy example.

          kutzi added a comment -

          Agree that this seems like a workaround. Moreover the fix doesn't seem to be complete as HTTPS might terminate in the reverse proxy, so Stapler.getCurrentRequest().getScheme() would return 'http'

          So the only 'correct' way to operate Jenkins under https seems to simply configure the rootUrl to start with https. Otherwise it's IMO simply a configuration error.

          kutzi added a comment - Agree that this seems like a workaround. Moreover the fix doesn't seem to be complete as HTTPS might terminate in the reverse proxy, so Stapler.getCurrentRequest().getScheme() would return 'http' So the only 'correct' way to operate Jenkins under https seems to simply configure the rootUrl to start with https. Otherwise it's IMO simply a configuration error.

          Jesse Glick added a comment -

          Good point. If a reverse proxy is being used to add HTTPS support—a pretty common setup—then 460e508 might in fact be a major regression. Should https://github.com/jenkinsci/jenkins/pull/671 be backed out (other than the baseline tests in JenkinsGetRootUrlTest)?

          Jesse Glick added a comment - Good point. If a reverse proxy is being used to add HTTPS support—a pretty common setup—then 460e508 might in fact be a major regression. Should https://github.com/jenkinsci/jenkins/pull/671 be backed out (other than the baseline tests in JenkinsGetRootUrlTest )?

          John Cook added a comment -

          Oh wow, as I was writing my HTTPS proxy bug report, you guys were talking about this very thing!

          John Cook added a comment - Oh wow, as I was writing my HTTPS proxy bug report , you guys were talking about this very thing!

          Jesse Glick added a comment -

          OK, that is a serious regression so I am going to back out the change immediately, pending a better solution (or clearer description of the tradeoffs of the current solution).

          Jesse Glick added a comment - OK, that is a serious regression so I am going to back out the change immediately, pending a better solution (or clearer description of the tradeoffs of the current solution).

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/java/jenkins/model/Jenkins.java
          core/src/test/java/jenkins/model/JenkinsGetRootUrlTest.java
          http://jenkins-ci.org/commit/jenkins/40dcfcb18178aa1cd2e73688492b4c4578be6968
          Log:
          JENKINS-16368 Reverted faulty fix.


          You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
          To unsubscribe from this group, send email to jenkinsci-commits+unsubscribe@googlegroups.com.
          For more options, visit https://groups.google.com/groups/opt_out.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/jenkins/model/Jenkins.java core/src/test/java/jenkins/model/JenkinsGetRootUrlTest.java http://jenkins-ci.org/commit/jenkins/40dcfcb18178aa1cd2e73688492b4c4578be6968 Log: JENKINS-16368 Reverted faulty fix. – You received this message because you are subscribed to the Google Groups "Jenkins Commits" group. To unsubscribe from this group, send email to jenkinsci-commits+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out .

          I agree, it's a regression.

          As far as I can say the root url is sent via mail or rss, so I think relative urls wont do.

          Oliver Gondža added a comment - I agree, it's a regression. As far as I can say the root url is sent via mail or rss, so I think relative urls wont do.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2224
          JENKINS-16368 Reverted faulty fix. (Revision 40dcfcb18178aa1cd2e73688492b4c4578be6968)

          Result = SUCCESS
          Jesse Glick : 40dcfcb18178aa1cd2e73688492b4c4578be6968
          Files :

          • changelog.html
          • core/src/test/java/jenkins/model/JenkinsGetRootUrlTest.java
          • core/src/main/java/jenkins/model/Jenkins.java

          dogfood added a comment - Integrated in jenkins_main_trunk #2224 JENKINS-16368 Reverted faulty fix. (Revision 40dcfcb18178aa1cd2e73688492b4c4578be6968) Result = SUCCESS Jesse Glick : 40dcfcb18178aa1cd2e73688492b4c4578be6968 Files : changelog.html core/src/test/java/jenkins/model/JenkinsGetRootUrlTest.java core/src/main/java/jenkins/model/Jenkins.java

          Jesse Glick added a comment -

          The root URL is indeed used in some mail messages, RSS, etc., but this is a different use case from what was originally filed—these cases are not using ConsoleAnnotator, and there is in general no current Stapler request anyway. (Maybe for RSS, definitely not for mail.) For such miscellaneous cases, where Jenkins must of necessity emit a complete URL, the administrator must configure the Jenkins root URL manually.

          The question is whether in generated pages containing internal links, especially console logs, we can use relative URLs to ensure that the link targets are correct even if the Jenkins root URL was not correctly configured.

          Jesse Glick added a comment - The root URL is indeed used in some mail messages, RSS, etc., but this is a different use case from what was originally filed—these cases are not using ConsoleAnnotator , and there is in general no current Stapler request anyway. (Maybe for RSS, definitely not for mail.) For such miscellaneous cases, where Jenkins must of necessity emit a complete URL, the administrator must configure the Jenkins root URL manually. The question is whether in generated pages containing internal links, especially console logs, we can use relative URLs to ensure that the link targets are correct even if the Jenkins root URL was not correctly configured.

          kutzi added a comment -

          I'd argue that the root URL must always be configured correctly. There's already a big warning on the global config page if you don't. Maybe we can still improve the documentation a bit to make the situation clearer for users.
          And then I'd close this a not-a-bug.

          kutzi added a comment - I'd argue that the root URL must always be configured correctly. There's already a big warning on the global config page if you don't. Maybe we can still improve the documentation a bit to make the situation clearer for users. And then I'd close this a not-a-bug.

          Perhaps this would be less destructive https://github.com/jenkinsci/jenkins/pull/682.

          It uses /job/stuff/1/console instead of https://server/job/stuff/1/console.

          Oliver Gondža added a comment - Perhaps this would be less destructive https://github.com/jenkinsci/jenkins/pull/682 . It uses /job/stuff/1/console instead of https://server/job/stuff/1/console .

          Jesse Glick added a comment -

          Not sure about #682. It introduces yet another way of creating URLs in Jenkins, adding to a confusing mix (and not helping Jelly pages which still have only ${rootURL}.) It is unnecessary if Jenkins.rootUrl is correctly configured, and inferior to emitting relative links if it is not. (#682 will still produce 404s if you have a reverse proxy which changes the effective context path but have not configured rootUrl.) If it is necessary to handle an unconfigured rootUrl—which is debatable—then we ought to do it right, I think.

          Jesse Glick added a comment - Not sure about #682. It introduces yet another way of creating URLs in Jenkins, adding to a confusing mix (and not helping Jelly pages which still have only ${rootURL }.) It is unnecessary if Jenkins.rootUrl is correctly configured, and inferior to emitting relative links if it is not. (#682 will still produce 404s if you have a reverse proxy which changes the effective context path but have not configured rootUrl .) If it is necessary to handle an unconfigured rootUrl —which is debatable—then we ought to do it right, I think.

          vjuranek added a comment -

          Hi,
          imposing URL scheme from Jenkins root URL doesn't seem as a completely correct approach. Use URL like /computer seems to me as a better approach (that's why I use it in disk-usage [1]) - not completely sure if it breaks when there's a reverse proxy which changes root context, need to set it up and pay with it for a while (AFAIK our admins use such setup in some cases without problems you described)

          [1] https://github.com/jenkinsci/disk-usage-plugin/commit/5c0f68cc0f839918ca811bedaba37c4c031a0535

          vjuranek added a comment - Hi, imposing URL scheme from Jenkins root URL doesn't seem as a completely correct approach. Use URL like /computer seems to me as a better approach (that's why I use it in disk-usage [1] ) - not completely sure if it breaks when there's a reverse proxy which changes root context, need to set it up and pay with it for a while (AFAIK our admins use such setup in some cases without problems you described) [1] https://github.com/jenkinsci/disk-usage-plugin/commit/5c0f68cc0f839918ca811bedaba37c4c031a0535

          Jesse Glick added a comment -

          @vjuranek I think your comment about disk-usage is misleading, because you are in that case returning a path which is resolved against the Jenkins context path by infrastructure, not a URL directly emitted to HTML.

          Jesse Glick added a comment - @vjuranek I think your comment about disk-usage is misleading, because you are in that case returning a path which is resolved against the Jenkins context path by infrastructure, not a URL directly emitted to HTML.

          vjuranek added a comment -

          sorry, you are right, it's different case.
          As for reverse proxy changing context root - it seems you are right, in such case the links are broken. However, doing so would break things anyway, it's even mentioned in [1] that context root cannot be changed.

          [1] https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache

          vjuranek added a comment - sorry, you are right, it's different case. As for reverse proxy changing context root - it seems you are right, in such case the links are broken. However, doing so would break things anyway, it's even mentioned in [1] that context root cannot be changed. [1] https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache

          Jesse Glick added a comment -

          AFAIK proxying with a different context path ought to work so long as you configure {[rootUrl}} correctly to the publicly visible URL. Maybe @Kohsuke can say why he wrote https://wiki.jenkins-ci.org/pages/diffpagesbyversion.action?pageId=9043974&selectedPageVersions=10&selectedPageVersions=9 and whether that was specific to some detail of mod_proxy.

          Jesse Glick added a comment - AFAIK proxying with a different context path ought to work so long as you configure {[rootUrl}} correctly to the publicly visible URL. Maybe @Kohsuke can say why he wrote https://wiki.jenkins-ci.org/pages/diffpagesbyversion.action?pageId=9043974&selectedPageVersions=10&selectedPageVersions=9 and whether that was specific to some detail of mod_proxy.

          John Cook added a comment -

          Is there going to be a hotfix for this issue? My JNLP clients literally cannot connect and I can't do any iOS builds right now. And I can't (easily) rollback my Jenkins version.

          John Cook added a comment - Is there going to be a hotfix for this issue? My JNLP clients literally cannot connect and I can't do any iOS builds right now. And I can't (easily) rollback my Jenkins version.

          Jesse Glick added a comment -

          @jcook793: if you cannot wait for the next regular Jenkins build then I would recommend building from trunk sources.

          Jesse Glick added a comment - @jcook793: if you cannot wait for the next regular Jenkins build then I would recommend building from trunk sources.

          vjuranek added a comment -

          Configuring Jenkins URL in a way kutzi proposed earlier (//elsewhere.net/something) seems to work correctly, i.e. links are HTTP on HTTP and HTTPS on HTTPS, so under assumption that such setup doesn't break anything else (which I haven't discovered yet) I agree to close as it as not a bug.

          vjuranek added a comment - Configuring Jenkins URL in a way kutzi proposed earlier (//elsewhere.net/something) seems to work correctly, i.e. links are HTTP on HTTP and HTTPS on HTTPS, so under assumption that such setup doesn't break anything else (which I haven't discovered yet) I agree to close as it as not a bug.

          kutzi added a comment -

          @vjuranek: I'm sure that might break some things - like when you try to use the root url in e-mails.
          Network-path references will only work in the context of a current request - AFAIK

          BTW: I didn't really propose to use this for the root URL. I just pointed out that this might be a solution in some way.

          kutzi added a comment - @vjuranek: I'm sure that might break some things - like when you try to use the root url in e-mails. Network-path references will only work in the context of a current request - AFAIK BTW: I didn't really propose to use this for the root URL. I just pointed out that this might be a solution in some way.

          vjuranek added a comment -

          @kurzi: right, sorry (sorry to all, I replied in hurry and didn't read the discussion very carefully, also broken email were mentioned earlier in the discussion )

          @jglick: as for broken reverse proxy, if I'm not mistaken, rootUrl for jelly pages (used e.g. in layout.jelly) is setup in Functions#initPageVariables() [1] and not from configured Jenkins URL

          [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/Functions.java#L167

          vjuranek added a comment - @kurzi: right, sorry (sorry to all, I replied in hurry and didn't read the discussion very carefully, also broken email were mentioned earlier in the discussion ) @jglick: as for broken reverse proxy, if I'm not mistaken, rootUrl for jelly pages (used e.g. in layout.jelly) is setup in Functions#initPageVariables() [1] and not from configured Jenkins URL [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/Functions.java#L167

          Jesse Glick added a comment -

          Huh. Well if the current Stapler request is used to create a server-absolute URL then definitely reverse proxies would be broken unless the context path happens to match on each side. Not sure why this does not use Jenkins.rootUrl when defined. (Or use ../ multiplied by the depth of the current URI relative to the context root.) There seem to be several contradictory ways of resolving URLs and no clear guidance on which should be preferred and why. Maybe @Kohsuke can explain it all.

          Jesse Glick added a comment - Huh. Well if the current Stapler request is used to create a server-absolute URL then definitely reverse proxies would be broken unless the context path happens to match on each side. Not sure why this does not use Jenkins.rootUrl when defined. (Or use ../ multiplied by the depth of the current URI relative to the context root.) There seem to be several contradictory ways of resolving URLs and no clear guidance on which should be preferred and why. Maybe @Kohsuke can explain it all.

          Ferry Huberts added a comment -

          I have the 'same' issue as in this bug (and bug 16511)

          I access my jenkins through a reverse apache httpd proxy, enforcing https on the apache side and using http on the jenkins side.

          since 1.500 my rss is broken.
          My 'Jenkins URL' is configured correctly with the https link

          Ferry Huberts added a comment - I have the 'same' issue as in this bug (and bug 16511) I access my jenkins through a reverse apache httpd proxy, enforcing https on the apache side and using http on the jenkins side. since 1.500 my rss is broken. My 'Jenkins URL' is configured correctly with the https link

          Jesse Glick added a comment -

          @fhuberts: the fix for HTTPS reverse proxies will I think be in 1.501. (The RC branch process is a little subtle so I am never entirely sure where a given change is going to first appear until the release is cut!)

          Jesse Glick added a comment - @fhuberts: the fix for HTTPS reverse proxies will I think be in 1.501. (The RC branch process is a little subtle so I am never entirely sure where a given change is going to first appear until the release is cut!)

          Ferry Huberts added a comment -

          @jesse awesome! thanks a bunch

          Ferry Huberts added a comment - @jesse awesome! thanks a bunch

          I wrote https://wiki.jenkins-ci.org/display/JENKINS/Hyperlinks+in+HTML that hopefully describes the current design of this in Jenkins.

          From that stand point,

          • I disagree with the initial fix (but this was backed out, so I'm good)
          • I also disagree with pull request #682, because it violates Rule #1: no absolute URLs in hyperlinks
          • The proper fix is to update HyperlinkNote so that it does not emit the absolute URL, and rather just use the context path from the current request (it shall fall back to the absolute URL if the code is without the thread-local request, such as when it's used for email-ext plugin)

          I'll make the fix accordingly.

          Kohsuke Kawaguchi added a comment - I wrote https://wiki.jenkins-ci.org/display/JENKINS/Hyperlinks+in+HTML that hopefully describes the current design of this in Jenkins. From that stand point, I disagree with the initial fix (but this was backed out, so I'm good) I also disagree with pull request #682 , because it violates Rule #1: no absolute URLs in hyperlinks The proper fix is to update HyperlinkNote so that it does not emit the absolute URL, and rather just use the context path from the current request (it shall fall back to the absolute URL if the code is without the thread-local request, such as when it's used for email-ext plugin) I'll make the fix accordingly.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          war/pom.xml
          http://jenkins-ci.org/commit/jenkins/ded37a2b626419fcef6e9ae425331c275d827b48
          Log:
          JENKINS-16368 "mvn hudson-dev:run" to run with context path

          This helps us catch a typical error of not using ${rootURL} or
          getContextPath() where needed.


          You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
          For more options, visit https://groups.google.com/groups/opt_out.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: war/pom.xml http://jenkins-ci.org/commit/jenkins/ded37a2b626419fcef6e9ae425331c275d827b48 Log: JENKINS-16368 "mvn hudson-dev:run" to run with context path This helps us catch a typical error of not using ${rootURL} or getContextPath() where needed. – You received this message because you are subscribed to the Google Groups "Jenkins Commits" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out .

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          plugins/pom.xml
          http://jenkins-ci.org/commit/jenkins/17d2df75ffdcf49d6026f67e250747481cf39c28
          Log:
          JENKINS-16368 "mvn hpi:run" to use non-empty context path.

          For a reason similar to ded37a2b626419fcef6e9ae425331c275d827b48,
          better to run with non empty context path.


          You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
          For more options, visit https://groups.google.com/groups/opt_out.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: plugins/pom.xml http://jenkins-ci.org/commit/jenkins/17d2df75ffdcf49d6026f67e250747481cf39c28 Log: JENKINS-16368 "mvn hpi:run" to use non-empty context path. For a reason similar to ded37a2b626419fcef6e9ae425331c275d827b48, better to run with non empty context path. – You received this message because you are subscribed to the Google Groups "Jenkins Commits" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out .

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2316
          JENKINS-16368 "mvn hudson-dev:run" to run with context path (Revision ded37a2b626419fcef6e9ae425331c275d827b48)

          Result = UNSTABLE
          kohsuke : ded37a2b626419fcef6e9ae425331c275d827b48
          Files :

          • war/pom.xml

          dogfood added a comment - Integrated in jenkins_main_trunk #2316 JENKINS-16368 "mvn hudson-dev:run" to run with context path (Revision ded37a2b626419fcef6e9ae425331c275d827b48) Result = UNSTABLE kohsuke : ded37a2b626419fcef6e9ae425331c275d827b48 Files : war/pom.xml

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2317
          JENKINS-16368 "mvn hpi:run" to use non-empty context path. (Revision 17d2df75ffdcf49d6026f67e250747481cf39c28)

          Result = SUCCESS
          kohsuke : 17d2df75ffdcf49d6026f67e250747481cf39c28
          Files :

          • plugins/pom.xml

          dogfood added a comment - Integrated in jenkins_main_trunk #2317 JENKINS-16368 "mvn hpi:run" to use non-empty context path. (Revision 17d2df75ffdcf49d6026f67e250747481cf39c28) Result = SUCCESS kohsuke : 17d2df75ffdcf49d6026f67e250747481cf39c28 Files : plugins/pom.xml

          Jesse Glick added a comment -

          AFAICT #682 does create app-relative URLs, or purports to.

          Jesse Glick added a comment - AFAICT #682 does create app-relative URLs, or purports to.

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          core/src/main/java/hudson/Functions.java
          core/src/main/java/hudson/console/HyperlinkNote.java
          core/src/main/java/jenkins/model/Jenkins.java
          http://jenkins-ci.org/commit/jenkins/9447289c87522d96d54228e817c5aa3cd04744c6
          Log:
          [FIXED JENKINS-16368]

          HyperlinkNote shouldn't emit the absolute URL.

          Compare: https://github.com/jenkinsci/jenkins/compare/902edc38aa26...9447289c8752


          You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
          For more options, visit https://groups.google.com/groups/opt_out.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/src/main/java/hudson/Functions.java core/src/main/java/hudson/console/HyperlinkNote.java core/src/main/java/jenkins/model/Jenkins.java http://jenkins-ci.org/commit/jenkins/9447289c87522d96d54228e817c5aa3cd04744c6 Log: [FIXED JENKINS-16368] HyperlinkNote shouldn't emit the absolute URL. Compare: https://github.com/jenkinsci/jenkins/compare/902edc38aa26...9447289c8752 – You received this message because you are subscribed to the Google Groups "Jenkins Commits" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out .

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2320
          [FIXED JENKINS-16368] (Revision 9447289c87522d96d54228e817c5aa3cd04744c6)

          Result = SUCCESS
          kohsuke : 9447289c87522d96d54228e817c5aa3cd04744c6
          Files :

          • core/src/main/java/hudson/console/HyperlinkNote.java
          • changelog.html
          • core/src/main/java/hudson/Functions.java
          • core/src/main/java/jenkins/model/Jenkins.java

          dogfood added a comment - Integrated in jenkins_main_trunk #2320 [FIXED JENKINS-16368] (Revision 9447289c87522d96d54228e817c5aa3cd04744c6) Result = SUCCESS kohsuke : 9447289c87522d96d54228e817c5aa3cd04744c6 Files : core/src/main/java/hudson/console/HyperlinkNote.java changelog.html core/src/main/java/hudson/Functions.java core/src/main/java/jenkins/model/Jenkins.java

            kohsuke Kohsuke Kawaguchi
            vjuranek vjuranek
            Votes:
            5 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated:
              Resolved: