Pages not deploying?
Erik Huelsmann
ehuels at gmail.com
Sun Jan 9 21:55:05 UTC 2022
Hi!
> >> I suspect it'll be easier and more robust to proxy to the pages daemon
> >> with
> >> appropriate rewrite rules than to use the Gitlab API.
> >
> > More robust probably --
> > but not easier.
> >
> > AFAICS the pages daemon just proxies to the other gitlab instance -
> > without knowing the last job ID I can't say Apache which URL to rewrite to.
>
> This surprises me. Perhaps the Gitlab setup on this server is
> significantly different than I expect, though.
>
> If we assume the following:
>
> 1. Gitlab Pages daemon is configured to listen on port 9000
> 2. The pages domain is configured to be $PAGES_DOMAIN (currently appears
> to be pages.example.com).
>
> Then Apache /should/ just need to take a request URL like
> https://common-lisp.net/project/$PROJECT/$PATH, overwrite the Host
> header to be $PROJECT.$PAGES_DOMAIN, and proxy it to
> http://localhost:9000/$PROJECT-site/$PATH
Yes. That should be an option. I have no idea why I didn't come up
with that before, instead using the somewhat complex construct of
resorting to disc access. Ah. I see. It's this bit of the apache
configuration which is the cause (caused by trying to support Mark E's
fetish for maintaining old URLs along the line of thought of "Good
URLs don't change"):
[snip: config sent in private]
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
More information about the clo-devel
mailing list