<div dir="ltr">Hi,<br><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 10:51 PM Raymond Toy <<a href="mailto:toy.raymond@gmail.com">toy.raymond@gmail.com</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">First, thanks for looking into this.<br></blockquote><div><br></div><div>No problem. Thanks for the discussion. It sharpens the final solution.<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">

>> the public_html directory had directories holding other<br>
>> artifacts like the pdf and html versions of the user manual and other<br>
>> documentation and, more importantly, the binaries of the various<br>
>> snapshots and releases.<br>
>><br>
>> How would this be handled?  I could check these items into the repo,<br>
>> but huge binary blobs in the repo that would just be copied out seems<br>
>> like not a good idea.<br>
><br>
><br>
> Correct. As in: adding the artifacts to a Git repository isn't really a great idea. I have 2 solutions: One using GitLab (preferred solution) and the other one based on the existing hosting setup on the filesystem.<br>
><br>
> The preferred solution is to upload the files into GitLab using the following command:<br>
><br>
>  $ curl --request POST --header "PRIVATE-TOKEN: <YOUR_PRIVATE_TOKEN>" --form "file=@/project/cmucl/public_html/downloads/release/21d/cmucl-src-21d.tar.bz2" <a href="https://gitlab.common-lisp.net/api/v4/projects/201/uploads" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/api/v4/projects/201/uploads</a><br>
><br>
> You can find the "201" in the URL above on the project homepage (<a href="https://gitlab.common-lisp.net/cmucl/cmucl-site" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/cmucl/cmucl-site</a>) which lists the "Project ID". The private token can be created on the account profile page at <a href="https://gitlab.common-lisp.net/profile/personal_access_tokens" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/profile/personal_access_tokens</a> (if you need to create on: you need to give it "API" scope; the others aren't required).<br>
><br>
<br>
This adds a bit of burden to anyone who is creating binaries for<br>
cmucl.  I currently have a cron job that runs rsync to grab<br>
public_html to my local machine for my own backup purposes.  How would<br>
that work in this scenario?<br></blockquote><div><br></div><div>It probably doesn't work too well: it's neither in the /project directories nor in the same directory from which GitLab pages hosts your website. Regardless, I can provide you with the paths to sync, but the mirror will still point to the GitLab instance for the hosted binaries.<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">
><br>
> The above is based on the info available from <a href="https://docs.gitlab.com/ee/api/projects.html#upload-a-file" rel="noreferrer" target="_blank">https://docs.gitlab.com/ee/api/projects.html#upload-a-file</a><br>
><br>
> The other option is that we map /project/*/downloads to <a href="https://common-lisp.net/project/*/downloads" rel="noreferrer" target="_blank">https://common-lisp.net/project/*/downloads</a> where the default path /project/*/downloads is a symlink to /project/*/public_html/downloads in order to make sure that all content in existing "downloads" directories remains correctly served. This option isn't my preference because it still requires people to have SSH access, whereas the first option means we can simply re-use existing GitLab authentication mechanisms (from where I stand as an admin, that is; as a user, you need to create the private token you didn't need before).<br>
<br>
As someone who already has ssh access, this is easiest because it<br>
preserves what already on disk.  And the cmucl mirrors, this probably<br>
preserves most of existing behavior.<br>
<br>
But wouldn't we need to move public_html out of the way so gitlab<br>
pages can serve the pages?</blockquote><div><br></div><div>Yes. There's no avoiding moving public_html out of the way.<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"> But if that's done, then you can't just<br>
point your browser to <a href="http://common-lisp.net/project/cmucl/downloads/" rel="noreferrer" target="_blank">http://common-lisp.net/project/cmucl/downloads/</a><br>
to see all of the files, right?<br></blockquote><div><br></div><div>Well, I was planning to adjust the Apache configuration to pick up the existence of /project/cmucl/downloads/ to serve files on the URL <a href="https://common-lisp.net/project/cmucl/downloads/">https://common-lisp.net/project/cmucl/downloads/</a> ; that way we can move public_html, but keep what used to be served from public_html/downloads/.<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">

I do agree with you that using uploaded files to gitlab makes a lot of<br>
sense.  If I were starting from scratch without any existing mirrors<br>
and my rsync backup, that seem to be the way to go.<br></blockquote><div><br></div><div>True. I think I'll document my preferred solution in the FAQ while you can use the solution which depends on the slightly adjusted Apache config I need to put in place. Would that slightly adjusted Apache config work for you for the uploads while still depending on GitLab to build your site?</div><div><br></div><div>Regards,</div><div><br></div><div><br></div><div>Erik.</div></div></div></div>