Posted by
GLASS mailing list on
Jan 09, 2019; 9:44pm
URL: https://forum.world.st/Seaside-compatibility-matrix-tp5093245p5093253.html
I'm a bit surprised that Johan would ignore build failures ... however
when I look at the cause of the failures I see that it is an issue with
GitHub hitting rate limits on it's API[1], which is a pretty annoying
... I can't guess why Johan would have let the tests fail without
contacting me and I don't see any open issues on the Seaside bug list ???
I've tried restarting a couple of the builds and they failed with rate
limit errors ... Tje GsDevLot/Seaside31 builds are passing[3] ...
Someone must manually update the .travis.yml file for each new version
of GemStone and I have made the (incorrect) assumption that Johan would
update the list periodically ... I assume that the versions that are
listed are the ones that he's using:)
If you want I can wade into this and figure out why the
GsDevKit/Seaside31 builds do not get rate limit errors ... I've
restarted one of the previously passing builds for GsDevKit/Seaside31[4]
to see if it will get a rate limit if run today ... the rate limits are
ip address based, so if you have the bad luck that any job running on a
particular vm has exceeded the rate limit ... all of the jobs running
for an hour (I think) will fail with the rate limit ...
The formerly passing job hit a rate limit ... so perhaps it's just a bad
day for hitting the API:)
Unfortunately there is no simple answer to minimizing the rate limit
errors other than avoid using tag matching in Metacello...
Dale
[1]
https://travis-ci.org/SeasideSt/Seaside/jobs/472290207#L1663-L1667[2]
https://github.com/SeasideSt/Seaside/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+gemstone[3]
https://travis-ci.org/GsDevKit/Seaside31/builds[4]
https://travis-ci.org/GsDevKit/Seaside31/jobs/257457547On 1/9/19 12:36 PM, Richard Sargent via Glass wrote:
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass