Proposal: project pages deployment through GitLab

[Erik Huelsmann]

Hi Vladimir,

On Tue, Oct 30, 2018 at 8:15 AM Vladimir Sedach <vas at oneofus.la> wrote:

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

Ah. Ok. My bad. I assumed TRAMP was a site generator.


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


Yes. Another assumption: everybody keeps their (site/software) assets in
source control/version control these days. Isn't your common-lisp.net site
versioned?


> and then requires you to use Gitlab


Sure. That's where you send your version controlled assets anyway, right?
On my part (as a maintainer of the site) this isn't much more effort since
everything required is already in place (from my perspective).


> (and it sounds like you also need to configure
> Gitlab Pages to know about files in your git repository),


Well, you'll be given that by me upon the initial creation/import of your
site into GitLab. All you need to do (when you want to go without a static
site builder) is to edit your pages and push them to your repo.

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.


I understand what you're saying and I appreciate the feedback. I also
understand you would be annoyed if the only way to deploy would be to go
through GitLab. Would you go so far as to say that you would move your
project pages elsewhere, though? (Not threatening or anything, really just
trying to understand your situation.)

As you have encountered already, this approach has problems.


Yea. I would assume every option has problems. The existing way of working
has problems as well in the sense that they put a maintenance effort on the
common-lisp.net admin team and I can fix issues from my mobile phone when I
need to deal with GitLab issues whereas I really need a computer with
terminal (I know there are terminals for phones, but they don't work for
me) to fix issues with any other part of the setup. Also, people expect
certain applications to be installed when logins are provided. GitLab
defines the service level pretty well and all that in a single installation
package.


> It is a nice option, but I do not think it should be the only option.
>

That's clear. Thanks a bunch for the feedback! I'll check what I can do to
allow multiple deployment methods to co-exist.

I'm eager to hear from others regarding this topic as well, though!

Regards,


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