Proposal: project pages deployment through GitLab

[Vladimir Sedach]

> While you're probably correct about the move from SourceForge to Trac,
> there's definitely not something like that going on in the current
> proposal: you use TRAMP to build your static assets and you will keep doing
> that, even after deployment moves to GitLab. GitLab Pages is - from a user
> perspective - nothing more than a pipeline which specifies where the
> generated output is.

TRAMP is not a static site generator, it is an Emacs virtual
file system for editing files and running commands remotely, that
works over SSH. I do not use a site generator for c-l.net projects.

> That pipeline/CI job builds your static content using
> your own preferred static site generator (in case of c-l.net, that's some
> amalgamation of cl-markdown, plump, cl-who, etc. and in your case that's
> TRAMP). Building in this context can be as simple as "take the pre-built
> pages stored in a Git repository and declare those to be the build output".
> The additional bit that Pages does is to take the output from a CI build
> and deploy it on the Pages host. This last step simply means the pages
> become available as https://common-lisp.net/project/<some-project>/...

My concern is that this requires you to use git, and then requires
you to use Gitlab (and it sounds like you also need to configure
Gitlab Pages to know about files in your git repository), all so that
Gitlab can copy some files to
https://common-lisp.net/project/<some-project>/. That is a lot of
dependencies if you only want to copy some files. As you have
encountered already, this approach has problems. It is a nice option,
but I do not think it should be the only option.

Vladimir