On Mon, Oct 29, 2018 at 3:38 AM Vladimir Sedach <
vas@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.