Unauthenticated use of api.github.com is rate limited; fails on Travis about whatwg.org

[foolip]

https://developer.github.com/v3/ is why I suspect rate limits.

@domenic said, re the sha:

That is indeed the purpose. As for why at build time, I'm not sure when else we would build the service worker?

[foolip]

@domenic, about this sha, is the only thing that would cause the service worker script to be reloaded a change to /service-workers.js, and does that mean that for standards that very rarely change, they won't get any improvements to the service worker script?

If the script has to be hosted on the same origin, and changing its content (as opposed to headers) is the only way, then we could perhaps set up a daily travis cron job that touches these files?

[domenic]

does that mean that for standards that very rarely change, they won't get any improvements to the service worker script?

I suppose so. However if the spec itself hasn't changed I'm not sure it really needs better service worker behavior.

I was more worried about cases like, us introducing some new image into the template, and then updating the service worker to cache that. But if we don't rebuild the spec at all, then it would not get the new template, so it doesn't need to cache the new image.

we could perhaps set up a daily travis cron job that touches these files?

Well, I don't want to cause unnecessary re-fetching either. Re-fetching the service worker code every day seems kind of sad.