Gitlab groups and publishing static web pages

Marco Antoniotti marco.antoniotti at unimib.it
Sun Mar 7 16:09:20 UTC 2021


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 at 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 at gmail.com> wrote:
>
>> Hi Marco,
>>
>> On Wed, Feb 24, 2021 at 9:09 PM Marco Antoniotti
>> <marco.antoniotti at 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
>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20210307/164b6ec9/attachment-0001.html>


More information about the clo-devel mailing list