Oh, very cool. I will have a look at that at some point, but I can't really do anything code-related until the pain subsides. (Right now I feel as if someone's pounded a large nail into my head.) Maybe you can co-ordinate with @E14n_twitter (I've confirmed in person that the's real Edward) to get more pages brought over and some CSS etc. done. He's got a branch with some work on this done already. And you guys have the password for the Netlify account, though it should just start working when the DNS is changed. Same for
lists.tlug.jp for the scraped copy of the current lists site. I didn't do any other subdomains; @ragga things we should just drop them and I agree. Everything should be pretty fully documented but ask here if you have questions.
Edward is on here using his twitter account, @E14n_twitter . That's why I mentioned it's ben verified by me, since you have no evidence otherwise that it's actually the same person @emiddleton that is a member of https://github.com/tlug.
At a quick glance, all looks good except the archive user/pw images which don't load on new.tlug.jp. Was that intentional?
In any case, lists.tlug.jp is now pointed at Jims server and looks to be working fine, which is kinda the most important as it's the portal for the mailing list.
Going forward, I think the main pages on both tlug.jp and lists.tlug.jp will have to be checked for consistency anyway.
Does netlify need to be changed to point to the new release branch each time?
We do not change the branch name holding the release; that would be as silly as changing the main branch name from
master every time we did a commit. Perhaps it's not clear, but the release branch is an entirely different set of files from the source branch. It's basically a commit of everything under the _site directory and nothing else.
Have you read through the docs on this?
Ah. BTW, I think you already know this, but I do strongly suggest rebase and fast-forward over actual merge commits. Anyway, the docs are all there, and hopefully do a better and more detailed job of describing the release process that I could by typing here. But if you have questions, I'll try to answer them. I would start by setting up a release branch for your dev branch and serving that from your personal netlify account, so you can have some confidence you understand what's going on. (@E14n_twitter may also be able to help; I think he's done this.)
Right now my branch is rebased on to master with everyone's latest stuff an no merge commits. If there's one command I can type right now, I'll do it. (./Test --prod-release ??) If it's more involved than that, I can look at it a little later. Really busy with work at the moment.
I don't know the exact git terminology, but you could set the github master branch to point to the same commit as dev/sjn/mediawiki-parser head and all would be good
No need for any additional merging/rebasing/etc.
Generally I do a quick read-through of all the commits I'm about to put on master before I do it, just to make sure they make sense, squash the "make mistake - do something else -fix previous mistake" commits, make sure the commits have explanations useful to others, and the like.
Ah, and if you also find a minor typo or something in the compiled site that could be fixed in the new version, that will also force a new commit to be built for the release branch, so the ID in that commit message will match a commit that still exists after the current one is not on any branches any more.
There are also commits where the message makes it appear as if the change does nothing, but in fact the site is broken in a major but non-obvious way without it, such as
d790d918d407c9fe2a. (The details of that are in the netlify-test repo.) I think it would be worth tweaking the message on any of those you notice, so we don't get someone a year from now saying "I disagree with that obvious aesthetic decision" and breaking the site.
Or hm, does that commit still leave the site broken, or maybe even break it? I don't even remember now! My guess is that the site is broken both before and after that commit?
Sounds like it's wrong in tlug.jp, then. It can be confirmed by testing with curl; I think I explained how to do that in
netlify-test. It looks like there may be enough stuff to be fixed on this branch that it might be worth just rolling it back to the previously released commit, re-releasing that, and then doing a pass to go through and fix things.
If you just grabbed all of Ed's commits, you definitely got a bunch of comits that were simply experiments on his part.
I also updated master, see if that looks better
It could be that Netlify has already fixed the case bug that was causing the multiple headers. I put in a bug report for it, though I don't know if it's publicly available. (I don't recall if I also posted it to https://community.netlify.com.) You could find out by deploying the netlify-test site (it may already be deployed in the TLUG account) and checking the three URLs there to see if any of them are still returning duplicate headers. (EDIT: Ah, yes, I think it should be up now on https://tlug-netlify-test.netlify.com/ .)