Build script improvements about whatwg.org

[domenic]

This is basically a dupe of whatwg/meta#24; not sure which to close.

[annevk]

We can have them both until it's fixed. Both are a natural place to search for this issue.

[annevk]

Another thing: @foolip and have noticed connection issues now and then. I just got hit by "Failed to connect to api.csswg.org port 443: Connection timed out" and we've got the same error for resources.whatwg.org. We could use https://docs.travis-ci.com/user/common-build-problems/#Timeouts-installing-dependencies to make Travis try again once or twice to not have to hit retry ourselves.

[annevk]

The current situation is really bad. I've basically no idea what's going with Infra at the moment:

$ curl --remote-name --fail https://resources.whatwg.org/build/deploy.sh && bash ./deploy.sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  4546  100  4546    0     0  21753      0 --:--:-- --:--:-- --:--:-- 21855
Commit = af5f4d000d4568fd060b7ff9a450c900a711e773
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 49857    0     0  100 49857      0  42841  0:00:01  0:00:01 --:--:-- 42869
curl: (22) The requested URL returned error: 500 Internal Server Error
The command "curl --remote-name --fail https://resources.whatwg.org/build/deploy.sh && bash ./deploy.sh" exited with 22.

Which curl failed here?

[annevk]

I created #159 which will help, but the main thing that needs looking into is the curl stuff.

[annevk]

So basically to improve the Bikeshed output we should also run curl https://api.csswg.org/bikeshed/ -F [email protected] -F output=err and maybe run that first. That way we have any warnings and such logged. We could even make it fail on any of those warnings. That seems best?

[annevk]

(What would be really nice is to send selective output from Travis back to the relevant GitHub PR so you don't have to scroll through a mostly useless log to get the information you need.)

[domenic]

A number of specs still have warnings, so we might need to be two-stage about it, first outputting errors then failing on warnings.

[annevk]

Another thing, to deal with the timeout we occasionally hit for the curl requests, we could specify --retry 2 or some such. This will retry the request when there's a timeout or 5xx response.

[annevk]

Observed timing out: resources.whatwg.org, api.csswg.org.
Connection problems observed: ^ and sideshowbarker.net (retry would not be effective to solve this one though).

[annevk]

As for commenting back to the GitHub PR: https://damien.pobel.fr/post/github-api-from-travisci/ can help with that. That seems like a nice thing to try to tackle before we make warnings (and lint errors) fatal. It does seem to require a GitHub token for each repository, so potentially a lot of additional configuration.

[domenic]

I personally don't like bot comments clogging up GitHub; if the build failed, there's already a nice red X you can click to see the details on the build failure. Pull request comments should be for discussion by humans.

[annevk]

I mainly don't like waiting on Travis CI to load and scanning through the sometimes rather large logs. But maybe now I've improved the logs it's not so much of a burden.

My suggestion would be to add --retry 2 to our curl calls and then consider this issue closed.

Once linting is there we can do a follow-up on making lint/warnings fatal.

Sounds good?

[domenic]

SGTM