Migrate GH Pages site to this repository

[alerque]

This entire repository is predicated on the assumption @simoncozens is in agreement with @rjmunro's comment here. If not we can just delete this whole repo and go our merry way.

I do think there is an advantage to having the site repository split. It will make cloning the main project that might lighter (as the binary blobs in this repo be excluded), separates the issue tracker, and will make tooling for automated released easier. Trying to manage CI build triggers in branches is less complicated that just triggering things on another repo.

To that end I extracted the gh-pages branch from the main sile repo and pushed it as the master branch of this repo.

Remaining tasks will need to be done by Simon since they involve the domain...

• [x] Verify the domain under the org account here.
• [x] Disable the GH Pages feature from the sile repo here by setting the "source" to none and removing the custom domain entry
• [x] Enable the GH Pages feature for this repo.
• [x] Add the custom domain to this repository here.
• [x] Update deprecated IP addresses of GH Pages service from DNS records.
• [x] Fix whatever you have to do so that HTTPS works and is Enforced.
• [x] Delete the gh-pages branch from the old repo here so that clones and forks stop picking it up.
• [x] Transfer all site related issues, see #9.

[simoncozens]

Agree this should be a separate repo. I'll sort it out when I get home. (Travelling ATM.)

[alerque]

Extended book tour?

[simoncozens]

Nope, just forgot. Sorry. We should be there now.

[alerque]

Thanks. You got a little carried away and checked off somethings that weren't done (fixing and enforcing HTTPS) but I've taken care of them.

One last thing that should be done on your end through your DNS provider ... it looks like the A record for the www. subdomain has been pointed to a CNAME record, but the A record for the bare domain has a hard coded IP address for GitHub Pages. I think the CNAME is the correct way to to this and should be done for the bare domain A record as well. It currently works, but won't load balance or migrate properly with any changes GitHub makes in the future.

[simoncozens]

Apparently the version of CNAME at the root of the domain is called ANAME. I've added one of them and removed the A records. Thanks for making the process very clear for me!

[alerque]

No problem. I've hosted and managed DNS servers at everything from the localhost to the ISP level for over 20 years and even contributed to bind and it's still sometimes black magic to me. You can actually use CNAME from root, but you can't mix and match it with other record types. It's all or nothing, and a lot of DNS servers don't like to do that. ANAME is not actually a standard DNS thing, but some providers use it as a way of papering over the machinery necessary to keep their hooks in the root domain while letting users CNAME as expected.

TL;DR: If ANAME is the option they gave you that's fine.

[rjmunro]

You can actually use CNAME from root, you can't mix and match it with other record types

IMHO This is way simpler and more obvious than it is often described. I really should write a blog post or something about this as it annoys me, but I don't have a blog :-).

CNAME tells a DNS client to redirect the whole domain to another place in the DNS hierarchy, so if you CNAME sile-typesetter.org to sile-typesetter.github.io, foo.sile-typesetter.org goes to sile-typesetter.github.io, mail (MX) for sile-typesetter.org goes to the mail server for sile-typesetter.github.io etc.

The alternative which is called ANAME by some DNS systems, (but other things by others) is instead of the DNS server telling the client "sile-typesetter.org is equivalent to sile-typesetter.github.io, go and ask them", the server instead goes and fetches the latest IP address from sile-typesetter.github.io and returns that as a normal A record to the client.

It might be better / faster to use an ANAME on www.sile-typesetter.org, depending on the caching that the ANAME server is doing of upstream - it could save the client having to make another request once it get's the CNAME response.

Because it's a server side thing, and on the DNS protocol level it just looks like a regular A record, it's not standardised and other providers call it different things. For example Cloudflare call it "CNAME Flattening". To use it, you misconfigure your whole root domain to be CNAMEd to another domain (a totally valid but different configuration), and it will ignore that configuration, and set up an ANAME instead.

[simoncozens]

Mythic Beasts wouldn't let me use a CNAME at root, which is why I used an ANAME...