<div dir="ltr">Hi Vladimir,<br><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 30, 2018 at 8:15 AM Vladimir Sedach <<a href="mailto:vas@oneofus.la">vas@oneofus.la</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> While you're probably correct about the move from SourceForge to Trac,<br>
> there's definitely not something like that going on in the current<br>
> proposal: you use TRAMP to build your static assets and you will keep doing<br>
> that, even after deployment moves to GitLab. GitLab Pages is - from a user<br>
> perspective - nothing more than a pipeline which specifies where the<br>
> generated output is.<br>
<br>
TRAMP is not a static site generator, it is an Emacs virtual<br>
file system for editing files and running commands remotely, that<br>
works over SSH. I do not use a site generator for <a href="http://c-l.net" rel="noreferrer" target="_blank">c-l.net</a> projects.<br></blockquote><div><br></div><div>Ah. Ok. My bad. I assumed TRAMP was a site generator.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

> That pipeline/CI job builds your static content using<br>
> your own preferred static site generator (in case of <a href="http://c-l.net" rel="noreferrer" target="_blank">c-l.net</a>, that's some<br>
> amalgamation of cl-markdown, plump, cl-who, etc. and in your case that's<br>
> TRAMP). Building in this context can be as simple as "take the pre-built<br>
> pages stored in a Git repository and declare those to be the build output".<br>
> The additional bit that Pages does is to take the output from a CI build<br>
> and deploy it on the Pages host. This last step simply means the pages<br>
> become available as <a href="https://common-lisp.net/project/" rel="noreferrer" target="_blank">https://common-lisp.net/project/</a><some-project>/...<br>
<br>
My concern is that this requires you to use git,</blockquote><div><br></div><div>Yes. Another assumption: everybody keeps their (site/software) assets in source control/version control these days. Isn't your <a href="http://common-lisp.net">common-lisp.net</a> site versioned?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and then requires you to use Gitlab</blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> (and it sounds like you also need to configure<br>
Gitlab Pages to know about files in your git repository),</blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> all so that Gitlab can copy some files to<br>
<a href="https://common-lisp.net/project/" rel="noreferrer" target="_blank">https://common-lisp.net/project/</a><some-project>/. That is a lot of<br>
dependencies if you only want to copy some files.</blockquote><div><br></div>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.)<br><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> As you have encountered already, this approach has problems.</blockquote><div><br></div><div>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 <a href="http://common-lisp.net">common-lisp.net</a> 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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It is a nice option, but I do not think it should be the only option.<br></blockquote><div><br></div><div>That's clear. Thanks a bunch for the feedback! I'll check what I can do to allow multiple deployment methods to co-exist.<br></div><div> </div><div>I'm eager to hear from others regarding this topic as well, though!</div><div><br></div><div>Regards,</div><div><br></div><div><br></div><div>Erik.<br></div><div><br></div><div><br></div></div></div></div>