Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    sssjjjnnn
    @sssjjjnnn
    Just added parameter handling
    Edward Middleton
    @E14n_twitter
    @sssjjjnnn I am here now. Sorry about not being around on the weekend.
    Jim Tittsler
    @jimt
    Is it OK to change the DNS for the web site? Is everything done?
    Henri "Ragga" Servomaa
    @ragga

    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.

    Jim Tittsler
    @jimt
    A lot of the links on new.tlug.jp front page appear to be broken (anything with wiki in the URL?).
    Henri "Ragga" Servomaa
    @ragga
    Yes, images in general seem to be missing.
    Curt J. Sampson
    @0cjs
    You guys did remember to regenerate the production release branch after committing the changes to master, right?
    sssjjjnnn
    @sssjjjnnn
    I haven't merged it yet. Does ./Test --dev-release work?
    Curt J. Sampson
    @0cjs
    Works fine, so long as you set up a site on netlify serving that branch.
    sssjjjnnn
    @sssjjjnnn
    What's the correct way to do it? Isn't it already set up on netlify?
    Does netlify need to be changed to point to the new release branch each time?
    Curt J. Sampson
    @0cjs
    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?
    sssjjjnnn
    @sssjjjnnn
    No, that's why I haven't merged anything yet
    Curt J. Sampson
    @0cjs
    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.)
    sssjjjnnn
    @sssjjjnnn
    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.
    Curt J. Sampson
    @0cjs
    And all commits on your local master are pushed up to GitHub?
    sssjjjnnn
    @sssjjjnnn
    There are none, my branch is clean with respect to the GitHub master
    Curt J. Sampson
    @0cjs
    I'm confused by "there are none"; you mean you have made commits on master and pushed them up, and so what's on GitHub's master is the same as what's on your master? Or they're the same because you haven't put any new commits on master?
    sssjjjnnn
    @sssjjjnnn
    I've never committed anything to master, my master is the same as GitHub
    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.
    Curt J. Sampson
    @0cjs
    Ah, ok. I see the last change on master is my last change. So the _site/ generated by that is still what's on the release branch, and running ./Test --prod-release will generate the same output, and so the commit to the release branch will be a do-nothing operation.
    sssjjjnnn
    @sssjjjnnn
    So I need to update master and then prod-release?
    Curt J. Sampson
    @0cjs
    But we're now getting to the point where we're the time you wait for me to type these answers is longer than it would be just to read the docs....
    sssjjjnnn
    @sssjjjnnn
    Okay...just give me a couple hours and I'll take care of it
    Curt J. Sampson
    @0cjs
    Yes. You add commits to the source branch, update the release branch with the new site generated from the latest commit, and push both. If you don't push the source branch, you end up with a released site that nobody can regenerate.
    sssjjjnnn
    @sssjjjnnn
    Makes sense
    Curt J. Sampson
    @0cjs
    Some people may find it confusing that you put a whole bunch of "WIP" commits on master; normally WIP means "this commit should never go on master branch".
    sssjjjnnn
    @sssjjjnnn
    Ah, forgot about those
    Curt J. Sampson
    @0cjs
    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.
    sssjjjnnn
    @sssjjjnnn
    Do you want me to squash those?
    Curt J. Sampson
    @0cjs
    Yeah, I'd say go do a cleanup-pass and force-push it. Nobody's likely to have the new version for a while yet.
    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.
    Curt J. Sampson
    @0cjs
    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?
    sssjjjnnn
    @sssjjjnnn
    According to the info in netlify-test, it should be uppercase, but the last commit in the tlug.jp repo was lowercase
    Curt J. Sampson
    @0cjs
    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.
    sssjjjnnn
    @sssjjjnnn
    I just fixed the tlug.jp to be uppercase as per netlify-test. But the current site, which is what I deployed before with lowercase doesn't seem to be sending me two headers
    I also updated master, see if that looks better
    Curt J. Sampson
    @0cjs
    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/ .)
    sssjjjnnn
    @sssjjjnnn
    Wiki pages are returning two headers
    CSS and index.html are okay
    I see, that header is only for wiki/*
    Well, let's try uppercase
    Curt J. Sampson
    @0cjs
    Yeah, that's the bug. master branch looks good now, and the Content-Type fix has a good explanation. Is that not actually working? What about the headers from https://tlug-netlify-test.netlify.com/content-type/{lower,mixed,upper}?
    sssjjjnnn
    @sssjjjnnn
    Haven't deployed it yet
    Just did it