#hypothes.is

hypothesis/h#5664 (buildkite-pipeline - edcd522 : Nick Stenning): The build passed.

Change view : https://github.com/hypothesis/h/commit/edcd5224...

Build details : http://travis-ci.org/hypothesis/h/builds/56327577

hypothesis/h#5665 (buildkite-pipeline - 7844875 : Nick Stenning): The build has errored.

Change view : https://github.com/hypothesis/h/compare/edcd522...

Build details : http://travis-ci.org/hypothesis/h/builds/56327971

hypothesis/h#5666 (buildkite-pipeline - c118cb9 : Nick Stenning): The build passed.

Change view : https://github.com/hypothesis/h/compare/7844875...

Build details : http://travis-ci.org/hypothesis/h/builds/56328303

nickstenn: what's this buildkite thing?

tilgovi: hey there -- it's a build pipeline service

I'm just experimenting atm

cool

I was wondering if it replaced travis

but it looks very nice indeed

yes, it would

it's essentially just a web service and an open-source "agent" that you run on your build servers

(so we'd need to run our own build server or servers)

but it has some nice properties:

- built in support for running build steps in docker containers

- build artifacts (we can build prod extensions)

- manual release steps

so I'm thinking we could automate the deployment to the chrome store

so that deploying to production is a one-click operation, and everyone can see both the dokku log and the deployment to the chrome store

nice

eventually FF, too

yes, of course

btw, I'd love your thoughts on how we solve the current blocker for FF

the static assets issue

issue?

actually, this is easy. It just hit me.

I was assuming that since we can't bundle the iframe source that we would be loading it from the server and then getting server-side assets for the iframe

that mixes poorly with the injected assets, which are bundled

but maybe we could have the server generate an app.html for the FF extension that has resource:// urls

<shrug>

issue for another time

i'm working on fun things today

good :)

oh this is going to be so sweet if it works out

cool

i'm working on es-http-parser

my joyent/http-parser -> emscripten -> js

an http parser for node?

the http parser from node compiled so it can run in the browser

node core takes joyent/http-parser and makes bindings for it from v8/c++ land exported into the runtime

do i... do i want to know why you want an http parser in the browser? :p

I'm just creating a similar binding using emscripten

So we can run server software as browser extensions ;)

sounds fun :)

Because the limit of decentralization is running our own stuff locally and I want that to be as easy as installing an app.

so I almost have express running inside a chrome extension

that's impressive

can you get access to a network socket, though?

yep

how would that work?

chrome packaged apps have a sockets API

oh my, you can!?

holy shit I did not know that

so I use browserify and hack the module resolution

make the builtin process object in the environment have a bindings function that returns my chrome.* API bindings in place of the node core v8 bindings to things

require('http') and you get the actual iojs/node http module code, but it's running against bindings that are JS on top of chrome.* rather than C++ on top of POSIX

process.binding('tcp_wrap') gives you back a simple wrapper around chrome's sockets API

process.binding('http_parser') gives you back the emscripten wrapper around the http praser

and net.js and http.js from the node source just work

it's pretty silly

tilgovi: sorry -- got distracted by dinner

it does indeed sound very silly

no worries

I'm just ramblin

tilgovi: well holy shit

?

tests run on buildkite in 2m

:)

ugh that's so much faster than travis

(because the docker image is already built)

oh, huh

they build and preserve the image between runs?

it's up to you

interesting

but the image is on your build server

ah, right

so yes, it's possible to preserve the image between runs

let me invite you to the project

tilgovi: when you're signed up, take a gander at https://buildkite.com/hypothesis/h/builds/6 if you like

i'm kind of tempted to remove the one test we currently have that requires elasticsearch

on the basis that the functionality it tests is already tested in annotator-store

yes

I've had exactly the same thought

please do

invited

err

signed up

to be fair, it's not testing anything that's actually part of annotator-store

it's testing our custom analyzer for the URI field

If we really want to do that, I think we could do it without ES, though.

Assume ES has a working pattern analyzer and just pull out the regex from the __analysis__ property of the model

test the regex directly

tilgovi: that's the realisation I've just come to

joy

but it certainly doesn't seem a test that's worth spinning up ES for