Document that LHCI server must own the entire origin

Hi, I’m trying to run the lhci server on a url like

http://dev-server.example.org/dev-tools/lighthouse-ci-server/app/

but the server tries to load everything relative to

http://dev-server.example.org/app/

for example http://dev-server.example.org/app/entry.fd7e7398.js. It also tries to redirect from http://dev-server.example.org/dev-tools/lighthouse-ci-server/ to http://dev-server.example.org/app/. I can’t find any way of setting the asset path at the moment but maybe I am missing something.

Would you be open to adding a base/public url or asset prefix config option for the server to support this use case?

I guess the mount path could be read on server startup but it looks like the asset path is set at build time so I’m not sure how easy this would be to configure at startup.

It looks like the upload command might already support this use case with the serverBaseUrl option, but I haven’t tested it. It would be great to have it for the server as well.

Thanks!

[jflayhart]

@nick-rudenko I think it will become more common to support this proxy stuff for bigger corporations having locked down servers, etc. Glad you asked! I happen to just write up a recipe for this setup.

Maybe it’s hacky, but it works by only exposing routes that matter for public-facing CI tools, while still keeping the LHCI web app GUI locked down and accessible behind VPN (doesn’t sacrifice security). It’s just what I had to do to get around the “must own entire origin” stuff cause I also was getting out of scope with my LHCI server if I had to make a subdomain!

Honestly, your best bet is probably a dedicated subdomain that can resolve paths relative baseUrl (ie origin). It just was more work for me to do that.

[patrickhulce]

Thanks for filing @niklasgrahl!

This is a thorny problem that would touch many layers of Lighthouse CI. Not only is the UI affected by every API client as well. The existing serverBaseUrl option you point out effectively only supports setting the origin at the moment. In fact I wonder if we should rename this to serverOrigin in 0.4.x to make that clearer 🤔

You’re also correct that because the base path is set at build time and we have SPA fake URL paths, any changing of the base path would require a custom build of the frontend code (or a significant rework of how the app references static assets).

Given all of these constraints and the considerable increase in testing surface it would require, I’m not sure this is something we can realistically consider for the near future of the project 😕

Happy to add whatever you think would be clear to the server documentation to make this limitation more upfront and obvious!