Proposal: project pages deployment through GitLab

[Erik Huelsmann]

Hi Vladimir,

Thanks for your reaction!

On Mon, Oct 29, 2018 at 3:38 AM Vladimir Sedach <vas at oneofus.la> wrote:

> [ .. snip .. ]
>


> This all seems like a very complicated way of hosting static files. I
> think trying to do something as fundamental as that by forcing it
> through a huge piece of software like Gitlab is a mistake. Six or
> eight years from now, Gitlab is going to go out of fashion, the way
> Trac has. If some people want to use Gitlab generated pages, that is
> a valuable feature right now, but it is not going to be very future
> proof.
>
> I use TRAMP and rsync to edit project pages and copy files and would
> definitely prefer to have plain SSH and SCP. It was a lot easier to
> transition project pages from HTML4 to XHTML to HTML5 with mobile
> support than it would have been to move from SourceForge to Trac to
> GitHub to Gitlab etc. Plain hosting also gives people the option of
> using their preferred static site generator instead of Gitlab.
>

 I see there's a bit of a misunderstanding going on and I apologize that I
wasn't more explicit on what this change would mean.

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

In that sense, while GitLab Pages may not be the fashion of tomorrow, this
isn't much of a problem because it's not dictating technology like Trac
used to do and as such qualifies (to me) as plain hosting. Basically the
only thing that changes is "plain (SSH) access" in the sense that GitLab
does your deployment, not rsync or SCP.

Is this how you understood GitLab Pages to work? If not, with this
additional explanation, how do you feel about the proposal?

Regards,


Erik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20181029/347e5f1d/attachment.html>