Pages not deploying?

Philipp Marek philipp at marek.priv.at
Sat Jan 8 18:21:54 UTC 2022


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


> If you do go via the API you'd need to ensure that every *-site repo 
> uses the
> same branch name (I think) and ensure that the artifacts for the latest 
> run
> are saved forever. For instance, it looks like the latest pages job at
> https://gitlab.common-lisp.net/cl-docker-images/cl-docker-images-site/-/jobs/24490
> has already had its artifacts purged.

Well, that would be another problem then, right.


> Unfortunately, I  can't easily tell when this last worked.  Maybe Apr
> 2021?  But I've also changed my ci config a bit.  The biggest change 
> was
> not needing to generate the pages with emacs; that change worked.  I've
> made some recent changes to see if my config  was broken in some way 
> and
> removed the constraint on deploying only from the master branch.  This
> didn't work.
> 
> If there's something I can do to help, please let me know.



Looking around some more, I found 
/var/log/gitlab/gitlab-pages/@4000000061d899ba05d2a384.s:

	...
	{
	  "content_type": "text/html; charset=utf-8",
	  "correlation_id": "01FRT0HT3ARTVAQQA14X18PF78",
	  "duration_ms": 83,
	  "error": "domain does not exist",
	  "host": "cmucl.pages.example.com",
	  "level": "info",
	  "method": "GET",
	  "msg": "access",
	  "pages_host": "cmucl.pages.example.com",
	  "pages_https": false,
	  "proto": "HTTP/1.1",
	  "referrer": "",
	  "remote_addr": "127.0.0.1:49094",
	  "remote_ip": "127.0.0.1",
	  "status": 200,
	  "system": "http",
	  "time": "2022-01-07T10:15:06Z",
	  "ttfb_ms": 78,
	  "uri": "/-/cmucl-site/-/jobs/26695/artifacts/public/doc/index.html",
	  "user_agent": "curl/7.74.0",
	  "written_bytes": 17807
	}


Perhaps we "just" need some job to extract the new artifact at the right 
location?

Reading the gitlab documentation (at [1]) makes me think that local 
serving
from a normal filesystem is no longer wanted...


Ad 1: 
https://docs.gitlab.com/ee/administration/pages/#prepare-gitlab-pages-for-140



More information about the clo-devel mailing list