There are a lot builds failing because the CSS seems not to be loaded. In most cases the test logs even don't have any notes, that loading the CSS failed. The reason for that is simple. We always return a HTTP 200 on the error page (as long as the message does not include database keywords). So if merging the CSS throws an exception the error page is served instead (with HTTP Status 200).
To avoid too many test failures when the CSS isn't loaded correctly I've build some code that automatically tries to add another style tag to the page to load the CSS again. In most cases that helps and the tests are running, but sometimes even that reload fails.
Nevertheless I think that might help to have a more stable build.
can we print out the response body (if any) when these methods fail? I'm curious what the error behind it is.
Be great to merge @sgiehl
We can otherwise also further look into it towards the end of year if needed and maybe the logged error messages help us find over time the root cause and find a solution
Was about to merge it when I realized, that even reloading the CSS didn't work in most cases. Logging the reposes and it header lead me to the right direction I guess. The response was always an empty response with status 200. Actually for both requests, even with an additional parameter. So I've tried with some debugging code, and it seems for some reason compressing the css fails and so an empty compressed file is stored. That empty file is automatically served with the next request.
I've now added an exception to be thrown when compressing a file does not work. That might actually solve the travis problem, as it should prevent storing an empty file and a direct regeneration of that file, as merging the file will be triggered a second time here