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