Re: Pages not deploying?

Philipp Marek <[email protected]>
Newsgroups gmane.lisp.common-lisp-net.devel
Message-ID <[email protected]>
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.