<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<br><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 1:54 AM 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">With your help, cmucl's web site can now be generated using gitlab<br>
pages.  This works great, once I move public_html out of the way.<br>
<br>
However, 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.</blockquote><div><br></div><div>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.</div><div><br></div><div>The preferred solution is to upload the files into GitLab using the following command:</div><div><br></div><div> $ 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/">https://gitlab.common-lisp.net/api/v4/projects/</a><b>201</b>/uploads<br></div><div><br></div><div>You can find the "201" in the URL above on the project homepage (<a href="https://gitlab.common-lisp.net/cmucl/cmucl-site">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">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></div><div><br></div><div><br></div><div>The above request will return something like:</div><div><br></div><div>{<br>  "alt": "dk",<br>  "url": "/uploads/66dbcd21ec5d24ed6ea225176098d52b/cmucl-src-21d.tar.bz2",<br>  "markdown": ""<br>}<br><br></div><div>The URL is relative to the project's URL, so the one returned above would expand to <a href="https://gitlab.common-lisp.net/cmucl/cmucl-site/uploads/66dbcd21ec5d24ed6ea225176098d52b/cmucl-src-21d.tar.bz2">https://gitlab.common-lisp.net/cmucl/cmucl-site/uploads/66dbcd21ec5d24ed6ea225176098d52b/cmucl-src-21d.tar.bz2</a></div><div><br></div><div>The above is based on the info available from <a href="https://docs.gitlab.com/ee/api/projects.html#upload-a-file">https://docs.gitlab.com/ee/api/projects.html#upload-a-file</a></div><div><br></div><div>The other option is that we map /project/*/downloads to <a href="https://common-lisp.net/project/*/downloads">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></div><div><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">Any suggestions?  Maybe we shouldn't really use<br>
gitlab pages?  (That would be kind of sad because automatically<br>
generating the site would make me more motivated to keep it a bit more<br>
up-to-date.)<br></blockquote><div><br></div><div><br></div><div>What's your take?</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div><br></div><div><br></div><div>Erik.<br></div><div><br></div><div><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>
On Sat, Nov 3, 2018 at 8:37 AM Erik Huelsmann<br>
<<a href="mailto:ehuelsmann@common-lisp.net" target="_blank">ehuelsmann@common-lisp.net</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> As per my prior mail, I'm sending instructions as to how to start using GitLab to deploy your project pages (i.e. how to deploy what you would normally copy to /project/*/public_html using GitLab automation).<br>
><br>
> First, the delpoyment through GitLab uses GitLab Pages which means that everything you can find about GitLab Pages based deployment of webpages (e.g. in the documentation: <a href="https://docs.gitlab.com/ee/user/project/pages/#how-it-works" rel="noreferrer" target="_blank">https://docs.gitlab.com/ee/user/project/pages/#how-it-works</a>) applies here as well -- except for the URL on which your site will be published.<br>
><br>
> Another important note is that if the directory /project/<your-project>/public_html exists, your pages will be served from that. If it doesn't, your project pages will be served from GitLab Pages, if that doesn't exist, your project pages are redirected to GitLab itself. This means that you can experiment with GitLab pages based deployment by moving your public_html directory out of the way. If your tests fail, simply move it back into place and your existing pages will be restored.<br>
><br>
> What do you need to do to use GitLab deployment?<br>
><br>
> 1. Create a GitLab repository called <project>-site in the group <project><br>
> 2. Add the content to be deployed to the repository (either static or to be built)<br>
> 3. Add a '.gitlab-ci.yml' file to the repository<br>
> 4. Rename the /project/<project>/public_html directory<br>
><br>
> For the simplest of deployments (taking what's in the repository "as-is") see the cl-couch pages deployment repository and .gitlab-ci.yml at <a href="https://gitlab.common-lisp.net/cl-couch/cl-couch-site/" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/cl-couch/cl-couch-site/</a>.<br>
><br>
> For an intermediary level deployment processing Markdown to HTML and wrapping the result in a template, see the <a href="http://common-lisp.net" rel="noreferrer" target="_blank">common-lisp.net</a> homepage generator (which we'd like to abstract into a generic tool; we can use a hand there!) at <a href="https://gitlab.common-lisp.net/clo/cl-site/" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/clo/cl-site/</a>.<br>
><br>
> For the most complex we currently have - using Docker - see the Quickref build at <a href="https://gitlab.common-lisp.net/quickref/quickref/tree/continuous-integration" rel="noreferrer" target="_blank">https://gitlab.common-lisp.net/quickref/quickref/tree/continuous-integration</a> ; note that this is currently on its "continuous-integration" branch. I hope it'll be adopted soon to be on the master branch.<br>
><br>
><br>
> I'll add similar instructions to the <a href="http://c-l.net" rel="noreferrer" target="_blank">c-l.net</a> FAQ.<br>
><br>
> Please feel free to follow-up with any questions you might have when you start playing around with this new feature.<br>
><br>
><br>
> Regards,<br>
><br>
> Erik.<br>
<br>
<br>
<br>
-- <br>
Ray<br>
</blockquote></div></div></div></div></div></div></div></div></div>