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
Viale Sarca 336
I-20126 Milan (MI) ITALY


--
Marco Antoniotti, Associate Professor         tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY