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