misc: add lhci dogfood script to travis

[patrickhulce]

Summary
Very early and very rough around the...everywhere, but at least enough to bump into lots of weird behavior that needs to be discussed how it should be handled :)

EDIT: This is probably too early to merge 😢, I fixed the bug where PRs get labeled as master branch because of the travis-side merge of the PR build in lhci repo but it's happening on this side again now :( fixed! travis docs don't seem to tell to truth or at least we seem to have different env variables set than documented and that exist over at lighthouse-ci repo, 🤷‍♂ oh well it works now!

[patrickhulce]

these two lines plus line 39 are all that we would expect a typical user to add to their travis

[patrickhulce]

I added these to our travis settings already

[paulirish]

yarn now-build will give you the same looking file in ./dist/now/english/index.html

[paulirish]

is using static-server too much of a pain?

or could we use python simplehttpserver?

[connorjclark]

python3 -m http.server 9000 works too

[patrickhulce]

did not expect such controversy over it haha, this is how I would've expected documenting this to a potential lhci user who might only have node in their environment so wanted to use it like they would.

I can switch to static-server.js if we'd prefer

[connorjclark]

Does that mean we'd be adding static-server and its features to our stable API?

[brendankenny]

Does that mean we'd be adding static-server and its features to our stable API?

I think the intention is for this to just test out lhci on the report, not be a general solution for folks using lhci (whether or not it should be written like the general solution is another question, but I guess this has the benefit of not needing another dep or download?)

[patrickhulce]

I think the intention is for this to just test out lhci on the report, not be a general solution for folks using lhci (whether or not it should be written like the general solution is another question, but I guess this has the benefit of not needing another dep or download?)

Yeah exactly.

Does that mean we'd be adding static-server and its features to our stable API?

Nope, this script has absolutely no bearing on the API for lighthouse or lhci. It's just about how we use lhci for our internal testing.

[paulirish]

kill $(jobs -p) would nuke all child processes. (in case the lhci commands also did backgrounded stuff.

but they don't. so it doesnt really matter. :)

[connorjclark]

what's the benefit of doing this here instead of in the /bin/bash shebang? all my personal scripts look like this:

#!/bin/bash -ex

...

[patrickhulce]

no benefit I'm aware of, just personal habit I suppose.

is there a benefit to doing it in the shebang? :)

[connorjclark]

i like one liners i guess

[patrickhulce]

oh after some googling I remembered I started this habit back at a company that used #!/usr/bin/env bash in all our scripts where the one-liner wasn't an option, so I guess that's one benefit of this set method is that it can be consistent across those two methods :)

[paulirish]

https://lhci-canary.herokuapp.com/app/projects neat

[brendankenny]

LGTM!

[brendankenny]

LHCI_CANARY_SERVER_TOKEN

does this mean only PRs from core contributors will get this?

[patrickhulce]

I could've sworn I replied to this already...

anyhoo, yes it's only available to core contributors at the moment, but that's not a hard requirement, we could loosen this and hardcode them if we wanted later they're not really that secret since you could find them out yourself given the URL of our server.