#hypothes.is

<nick> @robertknight there's one line in that PR that looks to me like it's not needed any more

<nick> otherwise, good to go

<robertknight> @nick - Indeed. Fixed

<chdorner> looking good. getting this out to production

<chdorner> I will keep it running for about 10-15 minutes before I run the migration that enforces that `annotation.document_id` is never empty

<robertknight> https://github.com/hypothesis/h/issues/3943 :facepalm: - I hate systems that let dumb errors like this creep in.

<nick> @robertknight "software," you mean?

<chdorner> well, Jinja should throw an error when the variable doesn't exist, no?

<chdorner> in a perfect world

<robertknight> By "system" I was leaving it open as to how exactly such mistakes get caught - whether via a runtime check, tests, static analysis etc.

<chdorner> alright, we are enforcing that each annotation has a document from now on, if that's not the case then we'll get data integrity errors

<robertknight> :+1:

<nick> @chdorner, @robertknight: Jinja can do that. It just doesn't do it by default.

<nick> And the reason it doesn't do it by default is because in a system (like most web applications) where templates are not explicitly tested for renderability, it makes more sense to render a slightly broken template than it does to throw an exception.

<nick> If we test all of our templates, then I'm more than happy to switch strictundefined on

<seanroberts> good morning

<seanroberts> @robertknight want to get the build out?

<robertknight> @seanroberts - Yes, just catching up with Sheetal. Be with you in a sec.

<seanroberts> :thumbsup:

<nick> god this NPM intermittent build failure thing is getting seriously tedious

<robertknight> I hear you

<nick> looks from the npm github issue tracker like this might be a problem in the npm client, not the registry

<nick> shall we bump the node version on travis to 4.4?

<nick> https://github.com/npm/registry/issues/10#issue...

<robertknight> Any reason not to go to 6.x? That will be the new LTR release very shortly

<nick> actually

<nick> we should

<nick> because we use 6.2.0 to build the production images

<robertknight> Also - perhaps we could just cache the `node_modules/` content in S3 using a hash of `package.json` as a key, with a fallback to `npm install` for PRs that include package.json changes.

<robertknight> Or perhaps use something that already exists

<nick> we do that already

<robertknight> Using Travis' caching system?

<nick> yep

<nick> but we still run `npm install` to handle any changes

<nick> anyway, it sounds from that thread like it was an issue with part of the npm client silently mapping `Connection: keep-alive` to `Connection: close`, so I'll open a PR to upgrade the version of Node we use on Travis.

<robertknight> If you want to bump Node in the other repos as well, feel free.

<robertknight> @seanroberts - Right. Client release time?

<seanroberts> :partyparrot:

<robertknight> ^ I'll merge the above once the client release is sorted

<chdorner> just having lunch, will miss the standup

<nick> http://i2.mirror.co.uk/incoming/article6665442....

<seanroberts> is readthedocs documentation an ok place to put the docs for how to deploy?

<lenazun> we have more docs on the playbook, that are more about the service