Clean lint from #1275

[paulmelnikow]

Ah, it makes sense that the lint test will only run on branches that have incorporated the commits which pulled them in. 😄

So the in-PR test results will be more reliable for new PRs than for old ones.

[espadrine]

Yes, better rerun Travis builds.

Also, make sure you try PRs (node server 1111 and open http://localhost:1111/try.html) and run npm test locally before merging.

[paulmelnikow]

Will do.

The idea would be to hit all the .svg endpoints that try.html loads.

What do you check? No 404's and no errors on the server?

[espadrine]

Depends on the PR. For those that add a badge, I verify that I see the badge, and that all advertised parameters work as intended. Since those PRs should add an example badge to try.html (if they don't, ask that they do), it's usually as simple as filtering to find the right badge.

For other types of patches, I typically verify that they don't break what they modify, and that they don't break the website.

For patches where I have performance concerns, I do performance analysis. The costly parts are text width measurement, heavy downloads and/or parsing, and graphics conversion.

[paulmelnikow]

What would you say classifies as a heavy download? In #888, for example, the code loads results for 100 builds at a time, paginating through as it looks for the right one. Each page is roughly 20 kb.

[espadrine]

Yeah we don't want to do that. In general, anything that isn't bounded in time or complexity, or that takes always more than 600 ms to load is not good. Also, anything that clogs up the file system… I have this old pain from the bower badge: it downloads code with a git process. I end up having this running in cron on all servers: https://github.com/badges/ServerScript/blob/master/remove-bower-cache.sh …

[paulmelnikow]

Re #888: Makes sense. I imagine 99% of projects will get the latest build in the first request. Maybe that would be acceptable. It would be nice to find a way to accomplish the dockerhub build status.

Re bower: Ugh, that is really messy. It must be slow and bandwidth-intensive too.

[paulmelnikow]

Possible alternative: #919