Hi
in the old days, when you created a project on CLNET you would also create a UN*X group with the project name. That seems sensible to me.
Gitlab can create "groups" (I do not know how this is related to the UN*X groups) and I would like to use the feature, but it seems that it is disabled in the CLNET instance. Could it be turned on?
Finally. I never remember how to post a set of static pages (created with HELambdaP) on the site. The instructions are not that helpful. Can anybody help?
Thanks
Marco
AFAIK, Erik Huelsmann can create a GitLab group for you (as a GitLab administrator). You just need to give him the name of the group that you request and then tell him which users should be invited into it.
BR ~phoe
On 13.12.2020 16:57, Marco Antoniotti wrote:
Hi
in the old days, when you created a project on CLNET you would also create a UN*X group with the project name. That seems sensible to me.
Gitlab can create "groups" (I do not know how this is related to the UN*X groups) and I would like to use the feature, but it seems that it is disabled in the CLNET instance. Could it be turned on?
Finally. I never remember how to post a set of static pages (created with HELambdaP) on the site. The instructions are not that helpful. Can anybody help?
Thanks
Marco
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043http://bimib.disco.unimib.it http://bimib.disco.unimib.it/ Viale Sarca 336 I-20126 Milan (MI) ITALY
Hi Marco,
As per phoe's mail, indeed I can create groups. To discern the idea that the bus factor here could be equal to 1, I'll add that so can Mark Evenson and Philipp Marek. Sending a mail to admin@common-lisp.net should be enough to get your request fulfilled. I think creating groups is similar to creating new projects - a privilege that used to be available to common-lisp.net admins only. Maybe we should reconsider, now that gitlab groups aren't tied to server administration directly and (more) liberally distribute the 'create group' bit? (Especially since it's no longer required to have groups on the physical box to publish project sites...)
As for deploying static pages, when you refer to "the instructions", do you mean the ones at https://common-lisp.net/faq/using-gitlab-deploy-project-pages ? If so, here's a working example of the simplest static site deployment you can get through GitLab for your project/group: https://gitlab.common-lisp.net/cl-couch/cl-couch-site
Regards,
Erik.
On Sun, Dec 13, 2020 at 4:58 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi
in the old days, when you created a project on CLNET you would also create a UN*X group with the project name. That seems sensible to me.
Gitlab can create "groups" (I do not know how this is related to the UN*X groups) and I would like to use the feature, but it seems that it is disabled in the CLNET instance. Could it be turned on?
Finally. I never remember how to post a set of static pages (created with HELambdaP) on the site. The instructions are not that helpful. Can anybody help?
Thanks
Marco
-- 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
On Sun, Dec 13, 2020 at 9:51 AM Erik Huelsmann ehuels@gmail.com wrote:
Hi Marco,
As for deploying static pages, when you refer to "the instructions", do you mean the ones at https://common-lisp.net/faq/using-gitlab-deploy-project-pages ? If so, here's a working example of the simplest static site deployment you can get through GitLab for your project/group: https://gitlab.common-lisp.net/cl-couch/cl-couch-site
If, like me, you didn't know where the published site is: http://common-lisp.net:/projects/cl-couch. The cl-couch repository should include a link.
A slightly more complex example is at https://gitlab.common-lisp.net/cmucl/cmucl-site for a site you're probably familiar with. In addition to the site, this also regenerates all the cmucl docs in html, pdf, and info format if possible. Thanks to Erik for helping set this up years ago! It's made it much easier since everything is automatic now instead of doing it by hand like I used to.
Regards,
Erik.
On Sun, Dec 13, 2020 at 4:58 PM Marco Antoniotti < marco.antoniotti@unimib.it> wrote:
Hi
in the old days, when you created a project on CLNET you would also create a UN*X group with the project name. That seems sensible to me.
Gitlab can create "groups" (I do not know how this is related to the UN*X groups) and I would like to use the feature, but it seems that it is disabled in the CLNET instance. Could it be turned on?
Finally. I never remember how to post a set of static pages (created with HELambdaP) on the site. The instructions are not that helpful. Can anybody help?
Thanks
Marco
-- 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
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Hi Ray, Everybody,
On Sun, Dec 13, 2020 at 7:10 PM Raymond Toy toy.raymond@gmail.com wrote:
On Sun, Dec 13, 2020 at 9:51 AM Erik Huelsmann ehuels@gmail.com wrote:
Hi Marco,
As for deploying static pages, when you refer to "the instructions", do you mean the ones at https://common-lisp.net/faq/using-gitlab-deploy-project-pages ? If so, here's a working example of the simplest static site deployment you can get through GitLab for your project/group: https://gitlab.common-lisp.net/cl-couch/cl-couch-site
If, like me, you didn't know where the published site is: http://common-lisp.net:/projects/cl-couch. The cl-couch repository should include a link.
Added a description to the repository which includes a link to the site (I've tested the link and the one above has 2 typos; the correct link is: https://common-lisp.net/project/cl-couch ).
A slightly more complex example is at https://gitlab.common-lisp.net/cmucl/cmucl-site for a site you're probably familiar with. In addition to the site, this also regenerates all the cmucl docs in html, pdf, and info format if possible. Thanks to Erik for helping set this up years ago! It's made it much easier since everything is automatic now instead of doing it by hand like I used to.
Good to hear the setup works well for you!
I hope I can help Marco get set up in a similar fashion.
Regards,
Erik.
Hi Everybody
Happy (Hacking) Holidays.
Ok. I am back doing this. Thank you Erik and thank you Ray for the tutorial :)
Let me understand how I need to proceed. But first let me tell you how I was working before.
In the past I would load my docs to my local clnet home and the I would copy them to the /project/public_html. As I use (shameless plug) HELambdaP to generate the documentation (* and ** below), I can keep everything in my folders and not use the .gitlab-ci.yml thingy.
Now I have the following problem, which I believe is affecting me (and others) either with or without .gitlab-ci.yml: the new projects do not have a "group" (a UN*X group) created automatically, which is what I was also hinting at with my first message. Cfr., my last project 'with-contexts'.
If I were to create a 'with-context-site' project in Gitlab, I would still have to ask you (the admins) for the creation of the 'with-context' group. My feeling is that the old ways were better, although I do not know what that entails about Gitlab "groups", which, I presume, are different from UN*X groups.
Now: is the move to Gitlab sites mandatory? If so, does that mean that we will need to have TWO projects going on separately? I.e. 'myproject' and 'myproject-site'? If the move is not mandatory, will the old way of manually copying documentation to '/projects/myproject/public_html' still work (provided that the 'group' was there)?
Before I conclude let me ask something else. (*) HELambdaP lives in sourceforge.net (http://helambdap.sf.net); a leftover from the CLNET interregnum, when things ceased to work (same for CLAST); I want to move it to CLNET and I will get around to do it. The question (**) is whether it would be possible to set up a job/task/whatever in common-lisp.net that would run it unattended. Since CLNET has a SBCL available (***), I suppose I could run it with an init script and have it ready to go, but wouldn't it be nice if the CL instance(s) running on CLNET, had Quicklisp running, so that HELambdaP (shameless plug again!) were just a quickload away? Or better, had the quickload in the instance init file? Maybe that would create issues between "site" quicklisp and "user" quicklisp, but it'd be nice to have.
All the best
Marco
(***) Can we have ABCL, ECL, CMUCL etc also installed? Just asking...
On Sun, Dec 13, 2020 at 7:27 PM Erik Huelsmann ehuels@gmail.com wrote:
Hi Ray, Everybody,
On Sun, Dec 13, 2020 at 7:10 PM Raymond Toy toy.raymond@gmail.com wrote:
On Sun, Dec 13, 2020 at 9:51 AM Erik Huelsmann ehuels@gmail.com wrote:
Hi Marco,
As for deploying static pages, when you refer to "the instructions", do you mean the ones at https://common-lisp.net/faq/using-gitlab-deploy-project-pages ? If so, here's a working example of the simplest static site deployment you can get through GitLab for your project/group: https://gitlab.common-lisp.net/cl-couch/cl-couch-site
If, like me, you didn't know where the published site is: http://common-lisp.net:/projects/cl-couch. The cl-couch repository should include a link.
Added a description to the repository which includes a link to the site (I've tested the link and the one above has 2 typos; the correct link is: https://common-lisp.net/project/cl-couch ).
A slightly more complex example is at https://gitlab.common-lisp.net/cmucl/cmucl-site for a site you're probably familiar with. In addition to the site, this also regenerates all the cmucl docs in html, pdf, and info format if possible. Thanks to Erik for helping set this up years ago! It's made it much easier since everything is automatic now instead of doing it by hand like I used to.
Good to hear the setup works well for you!
I hope I can help Marco get set up in a similar fashion.
Regards,
Erik.
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
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
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
Marco> Hi Ray I just checked writing the Marco> /project/myproject/public_html. It works for old projects.
Ah, didn't know that. I thought all projects got migrated.
Marco> I will have a look at the alternative setup for the "new", Marco> Gitlab-started projects as you suggested. I kinda wanted to Marco> avoid peppering the source tree with exogenous stuff like the Marco> .yml one. However, from what I understand from the cl-couch, Marco> cmucl-site and maxima-site examples, it should be sufficient Marco> for me to add pages: Marco> stage: deploy Marco> script: mv docs/html public Marco> artifacts: Marco> paths: Marco> - public Marco> tags: Marco> - site-gen Marco> only: Marco> - master
Marco> to, say, the with-context top directory? Or could I add it Marco> to the docs subdirectory only (changing the script entry)?
Something like that. I had to do quite a few experiments to get everything working. Not hard but it does take a bit of time. Putting in random prints was helpful too.
I find it super convenient to have CI handle the dirty work of even just copying the files so I don't have to remember when I updated the site.
-- Ray
Hi Marco, Ray,
On Sun, Dec 27, 2020 at 7:16 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi Ray
I just checked writing the /project/myproject/public_html. It works for *old projects*.
That's correct. I've asked project owners to move their site maintenance to GitLab; not all have found the time or inclination to do that and one or two pointed out that the new way of working would pose a problem for them. The current setup is to return pages from /project/*/public_html when that exists or to serve the pages from <project>-site alternatively.
[ snip ]
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)?
Yes, that's how it works (from the top directory, that is). The name of the repository/project should be with-context-site. The text after the "script:" key can be any command that needs to be executed in order to produce a top-level directory named "public".
Just asking for reassurances before trying it out...
All the best Thanks for your help
No problem. You're welcome. In case of more questions, don't hesitate to ask!
Marco
PS I understand the issues with having more than one CL implementation installed. No problems there...
We could look at having Docker images with the various CL implementations, which would allow you to choose your favorate implementation of the day. Not sure how easy it would be to make it available for CMUCL though.
Hi
I got back to this after some time.
So. I added the .yml file to the 'with-context' project and hoped it worked. Alas, it did not.
Now the question is what went wrong.
Is it because I insist on trying NOT to have a separate repository for the documentation? Anything else I can do?
Thanks
All the best
MA
On Mon, Dec 28, 2020 at 8:22 PM Erik Huelsmann ehuels@gmail.com wrote:
Hi Marco, Ray,
On Sun, Dec 27, 2020 at 7:16 PM Marco Antoniotti < marco.antoniotti@unimib.it> wrote:
Hi Ray
I just checked writing the /project/myproject/public_html. It works for *old projects*.
That's correct. I've asked project owners to move their site maintenance to GitLab; not all have found the time or inclination to do that and one or two pointed out that the new way of working would pose a problem for them. The current setup is to return pages from /project/*/public_html when that exists or to serve the pages from <project>-site alternatively.
[ snip ]
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)?
Yes, that's how it works (from the top directory, that is). The name of the repository/project should be with-context-site. The text after the "script:" key can be any command that needs to be executed in order to produce a top-level directory named "public".
Just asking for reassurances before trying it out...
All the best Thanks for your help
No problem. You're welcome. In case of more questions, don't hesitate to ask!
Marco
PS I understand the issues with having more than one CL implementation installed. No problems there...
We could look at having Docker images with the various CL implementations, which would allow you to choose your favorate implementation of the day. Not sure how easy it would be to make it available for CMUCL though.
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Hi
ok, I bit the bullet and created the "with-contexts-site" repository.
No pages generated. No joy.
I may have some other problem in my .yml file for sure (how do I debug that?), but re-reading the instructions ( https://common-lisp.net/faq/using-gitlab-deploy-project-pages) I see that there may be a bit missing in the very first step, where a "group" is mentioned. Which brings me back to the initial question I had about gitlab vs Unix groups.
Now. I presume that to fix the current issue, a "with-contexts" group could be created somewhere (Gitlab and/or Unix) and maybe the pages will be generated. However, this raises some other questions (which I will address later).
All the best
Marco
On Tue, Feb 23, 2021 at 2:43 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi
I got back to this after some time.
So. I added the .yml file to the 'with-context' project and hoped it worked. Alas, it did not.
Now the question is what went wrong.
Is it because I insist on trying NOT to have a separate repository for the documentation? Anything else I can do?
Thanks
All the best
MA
On Mon, Dec 28, 2020 at 8:22 PM Erik Huelsmann ehuels@gmail.com wrote:
Hi Marco, Ray,
On Sun, Dec 27, 2020 at 7:16 PM Marco Antoniotti < marco.antoniotti@unimib.it> wrote:
Hi Ray
I just checked writing the /project/myproject/public_html. It works for *old projects*.
That's correct. I've asked project owners to move their site maintenance to GitLab; not all have found the time or inclination to do that and one or two pointed out that the new way of working would pose a problem for them. The current setup is to return pages from /project/*/public_html when that exists or to serve the pages from <project>-site alternatively.
[ snip ]
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)?
Yes, that's how it works (from the top directory, that is). The name of the repository/project should be with-context-site. The text after the "script:" key can be any command that needs to be executed in order to produce a top-level directory named "public".
Just asking for reassurances before trying it out...
All the best Thanks for your help
No problem. You're welcome. In case of more questions, don't hesitate to ask!
Marco
PS I understand the issues with having more than one CL implementation installed. No problems there...
We could look at having Docker images with the various CL implementations, which would allow you to choose your favorate implementation of the day. Not sure how easy it would be to make it available for CMUCL though.
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- 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
Marco> Hi ok, I bit the bullet and created the "with-contexts-site" Marco> repository.
Marco> No pages generated. No joy.
Marco> I may have some other problem in my .yml file for sure (how Marco> do I debug that?), but re-reading the instructions Marco> (https://common-lisp.net/faq/using-gitlab-deploy-project-pages) Marco> I see that there may be a bit missing in the very first step, Marco> where a "group" is mentioned. Which brings me back to the Marco> initial question I had about gitlab vs Unix groups.
Marco> Now. I presume that to fix the current issue, a Marco> "with-contexts" group could be created somewhere (Gitlab Marco> and/or Unix) and maybe the pages will be generated. However, Marco> this raises some other questions (which I will address Marco> later).
My understanding is that the sites won't work with your personal "group" of Marco Antoniotti. Admins will have to create a new group for you where you can have your with-contexts-site. This is what I needed to do to get my fork of maxima to generate docs. It was originally on my personal group, but admins created a maxima group for me where I could have a maxima-site project to generate the pages I wanted.
-- Ray
Hi Ray
That's also what I surmised. However, suppose you wanted a Gitlab group herding several projects. How would that work?
Cheers
MA
On Wed, Feb 24, 2021 at 5:10 PM Raymond Toy toy.raymond@gmail.com wrote:
Marco> Hi ok, I bit the bullet and created the "with-contexts-site" Marco> repository. Marco> No pages generated. No joy. Marco> I may have some other problem in my .yml file for sure (how Marco> do I debug that?), but re-reading the instructions Marco> (https://common-lisp.net/faq/using-gitlab-deploy-project-pages) Marco> I see that there may be a bit missing in the very first step, Marco> where a "group" is mentioned. Which brings me back to the Marco> initial question I had about gitlab vs Unix groups. Marco> Now. I presume that to fix the current issue, a Marco> "with-contexts" group could be created somewhere (Gitlab Marco> and/or Unix) and maybe the pages will be generated. However, Marco> this raises some other questions (which I will address Marco> later).My understanding is that the sites won't work with your personal "group" of Marco Antoniotti. Admins will have to create a new group for you where you can have your with-contexts-site. This is what I needed to do to get my fork of maxima to generate docs. It was originally on my personal group, but admins created a maxima group for me where I could have a maxima-site project to generate the pages I wanted.
-- Ray
On Wed, Feb 24, 2021 at 8:14 AM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi Ray
That's also what I surmised. However, suppose you wanted a Gitlab group herding several projects. How would that work?
Yes. The cmucl group has 3 repos in it, but there's only one site repo. If you're asking if you can have more than one site repo in the group, then I don't know.
Cheers
MA
On Wed, Feb 24, 2021 at 5:10 PM Raymond Toy toy.raymond@gmail.com wrote:
Marco> Hi ok, I bit the bullet and created the "with-contexts-site" Marco> repository. Marco> No pages generated. No joy. Marco> I may have some other problem in my .yml file for sure (how Marco> do I debug that?), but re-reading the instructions Marco> (https://common-lisp.net/faq/using-gitlab-deploy-project-pages) Marco> I see that there may be a bit missing in the very first step, Marco> where a "group" is mentioned. Which brings me back to the Marco> initial question I had about gitlab vs Unix groups.
Marco> Now. I presume that to fix the current issue, a Marco> "with-contexts" group could be created somewhere (Gitlab Marco> and/or Unix) and maybe the pages will be generated. However, Marco> this raises some other questions (which I will address Marco> later).My understanding is that the sites won't work with your personal "group" of Marco Antoniotti. Admins will have to create a new group for you where you can have your with-contexts-site. This is what I needed to do to get my fork of maxima to generate docs. It was originally on my personal group, but admins created a maxima group for me where I could have a maxima-site project to generate the pages I wanted.
-- 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
Hi Ray
yes. That is exactly my question. I have WITH-CONTEXTS and OOK (let's say). Both now must have WITH-CONTEXTS-SITE and OOK-SITE repositories. Must why have their own group? Can they be in more than one group, like UNIX groups?
I know I should RTFM, but it is easier to ask :)
All the best
Marco
On Wed, Feb 24, 2021 at 7:00 PM Raymond Toy toy.raymond@gmail.com wrote:
On Wed, Feb 24, 2021 at 8:14 AM Marco Antoniotti < marco.antoniotti@unimib.it> wrote:
Hi Ray
That's also what I surmised. However, suppose you wanted a Gitlab group herding several projects. How would that work?
Yes. The cmucl group has 3 repos in it, but there's only one site repo. If you're asking if you can have more than one site repo in the group, then I don't know.
Cheers
MA
On Wed, Feb 24, 2021 at 5:10 PM Raymond Toy toy.raymond@gmail.com wrote:
Marco> Hi ok, I bit the bullet and created the "with-contexts-site" Marco> repository. Marco> No pages generated. No joy. Marco> I may have some other problem in my .yml file for sure (how Marco> do I debug that?), but re-reading the instructions Marco> (https://common-lisp.net/faq/using-gitlab-deploy-project-pages) Marco> I see that there may be a bit missing in the very first step, Marco> where a "group" is mentioned. Which brings me back to the Marco> initial question I had about gitlab vs Unix groups.
Marco> Now. I presume that to fix the current issue, a Marco> "with-contexts" group could be created somewhere (Gitlab Marco> and/or Unix) and maybe the pages will be generated. However, Marco> this raises some other questions (which I will address Marco> later).My understanding is that the sites won't work with your personal "group" of Marco Antoniotti. Admins will have to create a new group for you where you can have your with-contexts-site. This is what I needed to do to get my fork of maxima to generate docs. It was originally on my personal group, but admins created a maxima group for me where I could have a maxima-site project to generate the pages I wanted.
-- 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
-- Ray
Marco> Hi Ray yes. That is exactly my question. I have Marco> WITH-CONTEXTS and OOK (let's say). Both now must have Marco> WITH-CONTEXTS-SITE and OOK-SITE repositories. Must why have Marco> their own group? Can they be in more than one group, like Marco> UNIX groups?
Marco> I know I should RTFM, but it is easier to ask :)
Maybe. At the time I did this, I couldn't find any docs that mentioned this requirement. Perhaps I didn't look hard enough.
Hi Marco,
On Wed, Feb 24, 2021 at 9:09 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi Ray
yes. That is exactly my question. I have WITH-CONTEXTS and OOK (let's say). Both now must have WITH-CONTEXTS-SITE and OOK-SITE repositories. Must why have their own group? Can they be in more than one group, like UNIX groups?
I know I should RTFM, but it is easier to ask :)
In this case, it's better to ask, because the FM won't supply the answer. The problem is the setup of the URL structure of the https://common-lisp.net/ site, with all projects being subdirectories on the same top-level domain. The GitLab pages functionality that we use to host the project sites, wasn't designed with that in mind; instead, it was designed to be run on its own top-level domain where all subdomains get rerouted to GitLab Pages.
In order to be able to use GitLab Pages with our use-case, I've hacked around a restriction or two in the way GitLab manages its published web page assets. In order to keep things simple (that is: manageable with Apache mod_rewrite), I needed a fixed transformation from https://common-lisp.net/project/<project-name> to an on-disc path that might or might not exist when /project/<project-name> does not. In order to support the group/repo structure where */<project-name>-site is supported as a mapping, I no longer have a fixed mapping, because all '*' paths (group names) need to be checked for existence (GitLab stores its published webpages hierarchically).
Those are all *explanations*, not solutions. I'm thinking about available solutions, but don't have one quickly: checking more paths than the available fixed mapping, might run into clones of the repo. If that happens, which one of them is the true and leading one? (That is: what should the software do if there are ehuelsmann/ook-site, mantoniotti/ook-site and with-contexts/ook-site?)
Regards,
Hi Erik
thanks for the explanation. Let's say that I have a few complications in mind about what a user like me would like to have from CLNET GitLab pages, but we can discuss them later.
For the time being can we check what is happening with "with-contexts-site" and why it is not deploying? It looks like there is no "gitlab group".
All the best
Marco
On Sat, Feb 27, 2021 at 5:02 PM Erik Huelsmann ehuels@gmail.com wrote:
Hi Marco,
On Wed, Feb 24, 2021 at 9:09 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi Ray
yes. That is exactly my question. I have WITH-CONTEXTS and OOK (let's
say). Both now must have WITH-CONTEXTS-SITE and OOK-SITE repositories. Must why have their own group? Can they be in more than one group, like UNIX groups?
I know I should RTFM, but it is easier to ask :)
In this case, it's better to ask, because the FM won't supply the answer. The problem is the setup of the URL structure of the https://common-lisp.net/ site, with all projects being subdirectories on the same top-level domain. The GitLab pages functionality that we use to host the project sites, wasn't designed with that in mind; instead, it was designed to be run on its own top-level domain where all subdomains get rerouted to GitLab Pages.
In order to be able to use GitLab Pages with our use-case, I've hacked around a restriction or two in the way GitLab manages its published web page assets. In order to keep things simple (that is: manageable with Apache mod_rewrite), I needed a fixed transformation from https://common-lisp.net/project/<project-name> to an on-disc path that might or might not exist when /project/<project-name> does not. In order to support the group/repo structure where */<project-name>-site is supported as a mapping, I no longer have a fixed mapping, because all '*' paths (group names) need to be checked for existence (GitLab stores its published webpages hierarchically).
Those are all *explanations*, not solutions. I'm thinking about available solutions, but don't have one quickly: checking more paths than the available fixed mapping, might run into clones of the repo. If that happens, which one of them is the true and leading one? (That is: what should the software do if there are ehuelsmann/ook-site, mantoniotti/ook-site and with-contexts/ook-site?)
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Hi guys
apologies for being so nagging... But can you try to figure out what is not working with the "with-contexts-site" repository? Is it just the missing Gitlab group?
Thanks
Marco
On Sun, Feb 28, 2021 at 9:40 AM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi Erik
thanks for the explanation. Let's say that I have a few complications in mind about what a user like me would like to have from CLNET GitLab pages, but we can discuss them later.
For the time being can we check what is happening with "with-contexts-site" and why it is not deploying? It looks like there is no "gitlab group".
All the best
Marco
On Sat, Feb 27, 2021 at 5:02 PM Erik Huelsmann ehuels@gmail.com wrote:
Hi Marco,
On Wed, Feb 24, 2021 at 9:09 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi Ray
yes. That is exactly my question. I have WITH-CONTEXTS and OOK (let's
say). Both now must have WITH-CONTEXTS-SITE and OOK-SITE repositories. Must why have their own group? Can they be in more than one group, like UNIX groups?
I know I should RTFM, but it is easier to ask :)
In this case, it's better to ask, because the FM won't supply the answer. The problem is the setup of the URL structure of the https://common-lisp.net/ site, with all projects being subdirectories on the same top-level domain. The GitLab pages functionality that we use to host the project sites, wasn't designed with that in mind; instead, it was designed to be run on its own top-level domain where all subdomains get rerouted to GitLab Pages.
In order to be able to use GitLab Pages with our use-case, I've hacked around a restriction or two in the way GitLab manages its published web page assets. In order to keep things simple (that is: manageable with Apache mod_rewrite), I needed a fixed transformation from https://common-lisp.net/project/<project-name> to an on-disc path that might or might not exist when /project/<project-name> does not. In order to support the group/repo structure where */<project-name>-site is supported as a mapping, I no longer have a fixed mapping, because all '*' paths (group names) need to be checked for existence (GitLab stores its published webpages hierarchically).
Those are all *explanations*, not solutions. I'm thinking about available solutions, but don't have one quickly: checking more paths than the available fixed mapping, might run into clones of the repo. If that happens, which one of them is the true and leading one? (That is: what should the software do if there are ehuelsmann/ook-site, mantoniotti/ook-site and with-contexts/ook-site?)
Regards,
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
-- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it http://bimib.disco.unimib.it/ Viale Sarca 336 I-20126 Milan (MI) ITALY
Hi Marco,
On Sun, Mar 7, 2021 at 5:09 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi guys
apologies for being so nagging... But can you try to figure out what is not working with the "with-contexts-site" repository? Is it just the missing Gitlab group?
No problem! Sorry for not having been clear enough: yes, it's completely due to the missing group. (Just went over the rewrite rules in place and you're hitting the last rule: If there is no /project/with-contexts directory, redirect to the with-contexts group in GitLab -- which doesn't exist either. When you create the group *and* the site-group within it, you should see the site appear. I've added the group, so now the redirect from /project/with-contexts goes to an existing page...)
Thanks.
Now. I already have the two repositories ready and in the Gitlab (with-context and with-context-site).
How do I move them under the new group?
All the best
Marco
On Sun, Mar 7, 2021 at 5:33 PM Erik Huelsmann ehuels@gmail.com wrote:
Hi Marco,
On Sun, Mar 7, 2021 at 5:09 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi guys
apologies for being so nagging... But can you try to figure out what is
not working with the "with-contexts-site" repository? Is it just the missing Gitlab group?
No problem! Sorry for not having been clear enough: yes, it's completely due to the missing group. (Just went over the rewrite rules in place and you're hitting the last rule: If there is no /project/with-contexts directory, redirect to the with-contexts group in GitLab -- which doesn't exist either. When you create the group *and* the site-group within it, you should see the site appear. I've added the group, so now the redirect from /project/with-contexts goes to an existing page...)
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Hi,
On Wed, Feb 24, 2021 at 5:14 PM Marco Antoniotti marco.antoniotti@unimib.it wrote:
Hi Ray
That's also what I surmised. However, suppose you wanted a Gitlab group herding several projects. How would that work?
I haven't tried this, but GitLab supports nested groups these days (I don't think it'll work though).
Regards,
Erik.
-
Erik Huelsmann -
Marco Antoniotti -
Michał "phoe" Herda -
Raymond Toy