Re: Website upload

[Urs Liska]

Am 07.03.2017 um 11:24 schrieb 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. 

OK, there's some general discussion in here.

Basically I think such an upload should definitely include the --delete
option because we don't want an arbitrary number of orphaned files on
the server, isn't it?
But OTOH, as the current issue demonstrates, Google may point to these
files, and I'm not fully sure about the implications of these files
being removed. OTOH (again) there's no use in having unmaintained plain
HTML files lying around, and therefore the search engines should
presumably "forget" about these files, isn't it?

So my suggestion would be to add the --delete option to this rsync command.
In order to have a better place for discussing this specifically I've
created a pull request at
https://github.com/gperciva/gub/compare/master...uliska:patch-1

> 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. 

Could we also see that cron job script please?

> 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.

As said, my suggestion is to add the --delete option to both upload.py
and the website cron job.
However, in the current specific case I would vote for having a symlink
or redirect for http://lilypond.org/gsoc.html pointing to
http://lilypond.org/google-summer-of-code.html, at least unitl the
application stage is over.

Urs