Re: Website upload

[Phil Holmes]

Am 06.03.2017 um 23:43 schrieb Phil Holmes:
> > Simple answer - I run the GUB uploader.
> >
> > Slightly more useful one: there are two aspects to the "website": the
> > one that is created with "make website". This is a fairly simple
> > step, and any change to any file that is part of "website" is
> > automatically picked up by the website - it has a pair of cron jobs
> > that pull git and run "make website" every hour. The more complex
> > parts of the site (e.g. the docs) are created by GUB with a "make
> > lilypond" and then uploaded with a GUB command that rsynch's my disk
> > with lilypond.org.
> >
> > I suspect this won't answer your question, but does move the issue
> > forward. Please ask more - if I can answer, I will.
>
> OK. The concrete question (already raised by Federico) is:
> Whenever the *website* is uploaded (I don't talk about the manuals) does
> this involve rsync (seems so)? And if it does is the --delete option
> used? Because otherwise remainders of renamed nodes will be kept on the
> website (without being properly linked).

Again - this needs answering with a bit of care, because the website and the 
docs are closely linked.  It appears to me that putting any of the 
documentation (which includes part of the webite) is doen with rsync without 
the delete option.  See 
https://github.com/gperciva/gub/blob/master/test-lily/upload.py line 175. 
However, as I touched on earler, the website itself is created by a pull 
from git and then "make website".  The website itself is built into an 
offline directory and most of the files are then automatically rsynced to 
the live website - the cron job does this after make website has completed. 
Looking at the live website directory, it's apparent that there are a number 
of old files that haven't been built recently - including gsoc.html, which 
hasn't been touched since August 2012.

I've added Graham to the cc list to see if he thinks the best bet is simply 
to manually delete the old files, or create symlinks or something else.

> @node GSoC 2012
> will result in gsoc-2012.html, gsoc-2012.de.html etc.
>
> When that is renamed to
> @node Google Summer of Code
> the generated files are google-summer-of-code.html,
> google-summer-of-code.de.html etc.
>
> In that case the gsoc-2012... files have to be purged from the website.
> and somehow it looks this isn't the case, presumably leading to a huge
> amount of such orphaned files on the server.
>
> A special case (as brought up by Werner) is the fact that
> http://lilypond.org/gsoc.html is completely outdated but at the same
> time a prominent search result at Google. So if our assumption is
> correct and there are numeorus obsolete files on the server *this* one
> should note simply be deleted but redirected to
> http://lilypond.org/google-summer-of-code.html.
>
> Urs

--
Phil Holmes