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@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@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@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