Proposal: project pages deployment through GitLab

Erik Huelsmann ehuelsmann at common-lisp.net
Sun Oct 28 07:37:16 UTC 2018


Hi Vladimir,

On Sun, Oct 28, 2018 at 6:32 AM Vladimir Sedach <vas at oneofus.la> wrote:

> > Ok. Good. It's probably good to note that in my plans this type of
> project
> > page deployment will be the *only* supported way for project page
> > deployment once introduced. (Given the little feedback I received last
> time
> > I pitched the idea, I thought it was a good idea to mention this fact.)
> >
> > I've analysed the content of some of the largest /project/*/public_html
> > directories to prepare for this move. While we made a huge step in
> reducing
> > the content of public_html/ directories which wasn't really "site
> content"
> > (yet, rather Git or Darcs repositories), some of the largest ones are
> using
> > the public_html/ directory for binary artifact distribution (mostly
> release
> > binaries). I'll have a look at what we can do to support hosting that
> kind
> > of content (maybe with an artifact repository of some kind?) instead of
> > depending on public_html/ for it.
>
> I'm not following. What exactly does "importing the current project
> pages into GitLab repositories" entail, and why is that a problem for
> release tarballs? Is it not just putting the static site files into
> source control?
>

Yes, that's what it means. And for smaller numbers of tarballs that should
be fine. However, there are projects which host all releases since 2003 on
our site. Importing those into a Git repository would result in
gigabyte-sized
repositories. By themselves, having a Gigabyte sized repository isn't a
problem, but having to download all releases since 2003 (3GB?) in order to
make
a site update isn't practical and something I want to put projects through.
Once cloned, the project will even take double the space as the zip files
are
in the ref files as well as in the working directories of the git
repository.

Hence my idea that we need a means to manage those released files
separately.


> One other thing that should be preserved is hosting for user pages,
> like https://common-lisp.net/~vsedach/


Ok. Would it be problematic for you if the user-space would be
hosted/supported
the same way as the project pages will? As in: your personal "site" can be
dealt with through pushing to a git repository and the downloads managed
through
some means I yet need to figure out to deal with large(r) numbers of large
files.

I guess my question is: does your use-case get sufficiently covered by the
solution I'm proposing? (And if not, can you provide more details so I can
understand your use-case?)


Regards,

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


More information about the clo-devel mailing list