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,