Hi Vladimir,
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.
From what I understand, the proposed deployment mechanism just means that
we will have to push static site content to a git repository, then a pipeline will automatically put the files in the right place for serving. This is instead of another option which would be using ftp/scp/rsync to put the files to the correct location directly.
So we're depending on git, as well as the automatic deployment pipeline which is set up through gitlab.
From the user's perspective, if gitlab falls out of fashion next year,
there will be some other mechanism for doing the pipeline, and the pushing to git will remain the same (i.e. the user wouldn't see any difference).
If, in two years, git falls out of fashion, then the user will push their static files similarly using some other revision system other than git (likely with a similar workflow), so again it should not result in much disruption.
Question: will there be an opportunity in the pipeline to call e.g. "sbcl" in order to process the files, similar to what we are doing with c-l.net itself? Or will the pipeline be limited just to moving already-prepared static files into the correct location?
On Tue, Oct 30, 2018 at 3:48 PM Erik Huelsmann ehuelsmann@common-lisp.net wrote:
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.
On Tue, Oct 30, 2018 at 9:17 PM Dave Cooper david.cooper@genworks.com wrote:
From what I understand, the proposed deployment mechanism just means that we will have to push static site content to a git repository, then a pipeline will automatically put the files in the right place for serving. This is instead of another option which would be using ftp/scp/rsync to put the files to the correct location directly.
That's correct.
So we're depending on git, as well as the automatic deployment pipeline which is set up through gitlab.
That's correct too.
From the user's perspective, if gitlab falls out of fashion next year, there will be some other mechanism for doing the pipeline, and the pushing to git will remain the same (i.e. the user wouldn't see any difference).
Absolutely.
If, in two years, git falls out of fashion, then the user will push their static files similarly using some other revision system other than git (likely with a similar workflow), so again it should not result in much disruption.
That's what I'd say, yes.
Question: will there be an opportunity in the pipeline to call e.g. "sbcl" in order to process the files, similar to what we are doing with c-l.net itself?
Yes. You can definitely do more than just move your files into place: Just last night, I've built all of Quickref with our pipeline and had GitLab put it in the deployment location (for my testing purposes): http://new-quickref.common-lisp.net/
If you favorite content generator, Lisp or Golang tool isn't readily available, we can support installing those, or you can simply depend on the Docker images for your favorate tool (which GitLab will automatically grab for you).
Or will the pipeline be limited just to moving already-prepared static files into the correct location?
No. Absolutely not. The purpose is to help people with consistent deployment environments and for those who already worked with Git, to simplify deployment by offloading the deployment process to GitLab (which removes the need to build a site and then install it through scp or ssh after that, because GitLab takes care of both steps).
Regards,
Erik.
On Tue, Oct 30, 2018 at 3:48 PM Erik Huelsmann ehuelsmann@common-lisp.net wrote:
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.
-- My Best,
Dave Cooper, david.cooper@gen.works genworks.com, gendl.org +1 248-330-2979
Yes. Another assumption: everybody keeps their (site/software) assets in source control/version control these days. Isn't your common-lisp.net site versioned?
No, none of them are. Someone (I think it was Travis Cross) set up a repository for the Parenscript site sometime around 2010, but I did not continue using that. Emacs' version-control backup files (because they work transparently with TRAMP) do what I need.
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.)
I would not move them elsewhere.
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
Ok, now this makes a lot of sense. I had assumed that the everything-in-Gitlab approach would, if anything, also involve more system administration. If it makes running common-lisp.net easier, that overrides my concerns.
Vladimir
-
Dave Cooper -
Erik Huelsmann -
Vladimir Sedach