On Tue, Oct 30, 2018 at 8:15 AM Vladimir Sedach <
vas@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.