<div dir="ltr"><div>Hi Marco, Ray,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 27, 2020 at 7:16 PM Marco Antoniotti <<a href="mailto:marco.antoniotti@unimib.it">marco.antoniotti@unimib.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Ray</div><div><br></div><div>I just checked writing the /project/myproject/public_html.  It works for <b>old projects</b>.</div></div></blockquote><div><br></div><div>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.</div><div>The current setup is to return pages from /project/*/public_html when that exists or to serve the pages from <project>-site alternatively.<br></div><div><br></div><div>[ snip ]<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div></div><div>The updated OOK doc pages get loaded as expected (as you can check).</div><div><br></div><div>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 <span style="font-family:monospace">.yml </span>one.</div><div>However, from what I understand from the cl-couch, cmucl-site and maxima-site examples, it should be sufficient for me to add</div><div>
<pre lang="yaml"><span id="gmail-m_-2665822178852941765gmail-LC1" lang="yaml"><span>pages</span><span>:</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC2" lang="yaml">  <span>stage</span><span>:</span> <span>deploy</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC3" lang="yaml">  <span>script</span><span>:</span> <span>mv docs/html public</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC4" lang="yaml">  <span>artifacts</span><span>:</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC5" lang="yaml">     <span>paths</span><span>:</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC6" lang="yaml">       <span>-</span> <span>public</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC7" lang="yaml">  <span>tags</span><span>:</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC8" lang="yaml">    <span>-</span> <span>site-gen</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC9" lang="yaml">  <span>only</span><span>:</span></span>
<span id="gmail-m_-2665822178852941765gmail-LC10" lang="yaml">    <span>-</span> <span>master</span></span>
</pre>

</div><div><br></div><div>to, say, the with-context top directory?  Or could I add it to the docs subdirectory only (changing the <span style="font-family:monospace">script </span>entry)?<br></div></div></blockquote><div><br></div><div>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".<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div></div><div>Just asking for reassurances before trying it out...</div><div><br></div><div>All the best</div><div>Thanks for your help<br></div></div></blockquote><div><br></div><div>No problem. You're welcome. In case of more questions, don't hesitate to ask!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>Marco</div><div><br></div><div><br></div><div>PS  I understand the issues with having more than one CL implementation installed.  No problems there...<br></div></div></blockquote></div><br clear="all"><div>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.<br></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div></div>