[Glass] Seaside compatibility matrix?

[Dale Henrichs]

As I read about the (current) github rate limiting rules[1], I see that 
they state that you can make up to 60 unauthenticated requests per hour 
..  and of course on travis, you are sharing the rate limit with all 
jobs running from the same machine/ip address, so I'm not sure there is 
a useful solution .. if the rate limit is exceeded it seems that you 
might have to wait up to an hour before making another api request?

Authenticated requests can make 5000 requests per hour, but in order to 
enable authentication for travis jobs, you need to supply an encrypted 
token that can only be decrypted on a per user basis, so I'm not exactly 
sure that it is possible to do this for a shared github repository ...

Metacello uses the api to determine the list of tags that are available 
for a github project ... the alternative is use git and clone the 
repository locally so that you can get the list of tags by making an os 
call, but not everyone using Metacello has git installed ...

Here are the (two) places in the latest master branch that use tag matching:

BaselineOfSeaside3.package/BaselineOfSeaside3.class/instance/baselineadaptors..st:						repository: 'github://GsDevKit/gsApplicationTools:v1.?/repository' ];
BaselineOfSeaside3.package/BaselineOfSeaside3.class/instance/baselineadaptors..st:						repository: 'github://GsDevKit/zinc:v2.4.3.?/repository' ].

and both are conditional on GemStone and presumably neither is necessary 
... I've replaced both of the tag references with a branch reference and 
started a new travis job[2] ... and  we'll see if the builds will pass 
on travis ...

Dale

[1] https://developer.github.com/v3/#rate-limiting
[2] https://travis-ci.org/dalehenrich/Seaside/builds/477576459
On 1/9/19 1:44 PM, Dale Henrichs wrote:
>
> 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/257457547
>
>
> On 1/9/19 12:36 PM, Richard Sargent via Glass wrote:
>> In looking at https://github.com/SeasideSt/Seaside/, I see the latest 
>> Seaside
>> test results show failures for all GemStone versions (3.4.2, 3.3.6, 
>> 3.2.17.
>> & 3.1.0.6).
>>
>> How would I find out which Seaside releases have checked out as 
>> passing for
>> any given GemStone version?
>>
>> [Separately, I note that the latest "modern" GemStone releases are 
>> 3.4.3 &
>> 3.3.9.]
>>
>>
>> Thanks,
>> Richard
>>
>>
>>
>> -- 
>> Sent from: http://forum.world.st/GLASS-f1460844.html
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20190109/ad8e1b7e/attachment-0001.html>