Gitlab groups and publishing static web pages

Marco Antoniotti marco.antoniotti at unimib.it
Sun Dec 27 18:15:56 UTC 2020


Hi Ray

I just checked writing the /project/myproject/public_html.  It works for *old
projects*.

Here are the specifics (I am running this on the clnet machine)

*mantoniotti at common-lisp$* *ls -l /project/ | grep ook*
drwxrwsr-x 1 orphaned-projects cl-hooks                 22 Mar 29  2015
cl-hooks/
drwxrwsr-x 1 eenge             hyperspec-lookup         22 May 12  2015
hyperspec-lookup/
drwxr-sr-x 1 mantoniotti       ook                      22 Oct  6  2018 ook/
*mantoniotti at common-lisp$* *ls -l /project/ook*
total 0
drwxrwsr-x 1 mantoniotti ook 252 Oct 12  2018 public_html/

As you can see the /project/ook directory has its own UN*X group.  I am
part of that group, therefore I can write it no problem.  What has changed
is with the new projects, which do not get a UN*X group, as they are
created via Gitlab.

The updated OOK doc pages get loaded as expected (as you can check).

I will have a look at the alternative setup for the "new", Gitlab-started
projects as you suggested.  I kinda wanted to avoid peppering the source
tree with exogenous stuff like the .yml one.
However, from what I understand from the cl-couch, cmucl-site and
maxima-site examples, it should be sufficient for me to add

pages:  stage: deploy  script: mv docs/html public  artifacts:
paths:       - public  tags:    - site-gen  only:    - master


to, say, the with-context top directory?  Or could I add it to the docs
subdirectory only (changing the script entry)?

Just asking for reassurances before trying it out...

All the best
Thanks for your help

Marco


PS  I understand the issues with having more than one CL implementation
installed.  No problems there...


On Sun, Dec 27, 2020 at 3:36 AM Raymond Toy <toy.raymond at gmail.com> wrote:

>
>     Marco> Hi Everybody Happy (Hacking) Holidays.
>
>     Marco> Ok.  I am back doing this.  Thank you Erik and thank you Ray
>     Marco> for the tutorial :)
>
>     Marco> Let me understand how I need to proceed.  But first let me
>     Marco> tell you how I was working before.
>
>     Marco> In the past I would load my docs to my local clnet home and
>     Marco> the I would copy them to the /project/public_html.  As I use
>     Marco> (shameless plug) HELambdaP to generate the documentation (*
>     Marco> and ** below), I can keep everything in my folders and not
>     Marco> use the .gitlab-ci.yml thingy.
>
>     Marco> Now I have the following problem, which I believe is
>     Marco> affecting me (and others) either with or without
>     Marco> .gitlab-ci.yml: the new projects do not have a "group" (a
>     Marco> UN*X group) created automatically, which is what I was also
>     Marco> hinting at with my first message.  Cfr., my last project
>     Marco> 'with-contexts'.
>
>     Marco> If I were to create a 'with-context-site' project in Gitlab,
>     Marco> I would still have to ask you (the admins) for the creation
>     Marco> of the 'with-context' group.  My feeling is that the old ways
>     Marco> were better, although I do not know what that entails about
>     Marco> Gitlab "groups", which, I presume, are different from UN*X
>     Marco> groups.
>
>     Marco> Now: is the move to Gitlab sites mandatory?  If so, does that
>     Marco> mean that we will need to have TWO projects going on
>     Marco> separately? I.e. 'myproject' and 'myproject-site'?  If the
>     Marco> move is not mandatory, will the old way of manually copying
>     Marco> documentation to '/projects/myproject/public_html' still work
>     Marco> (provided that the 'group' was there)?
>
> Copying documentation to /projects/myproject/public_html no longer works
> I think.  The http server doesn't look there any more.  It's somewhere
> else; I'd have to look at my old emails to find out exactly where.  But
> I think that also doesn't matter because I don't think it's writable by
> you.
>
> I don't think you really need two projects, but I find it rather nice to
> separate out the site from the code.  However, as a hack I have
> https://gitlab.common-lisp.net/maxima/maxima-site which is a full copy
> of the maxima repo.  Except I only use it to build the docs
> automatically with each checkin.  I could build maxima if desired.
>
> But you do need admins to create the project group.  You can't use your
> personal group.
>
>     Marco> (***) Can we have ABCL, ECL, CMUCL etc also installed?  Just
>     Marco> asking...
>
> Cmucl requires 32-bit libraries.
>
> I think this is an unnecessary extra burden for the admins.  The problem
> is knowing exactly which version to have and when to update if needed.
> And managing the the versions because different projects may want
> different versions.
>
> I solve this myself in my CI config by downloading the appropriate
> version and using it.  Perhaps I could save some bandwidth by keeping it
> in an artifact so that it can just be reloaded from disk (?) instead of
> downloading it from c-l.net each time.
>
> --
> Ray
>


-- 
Marco Antoniotti, Associate Professor         tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20201227/2fc6a16b/attachment.html>


More information about the clo-devel mailing list