[Glass] Seaside compatibility matrix?

[Dale Henrichs]

The initial build passed without a rate limit violation, but that 
doesn't mean anything with regards to rate limits:), since the Seaside 
build itself was not necessarily exceeding the api rate limit ---  ... 
It does mean that Johan was not letting failing GemStone builds slide 
through:)...

I'm running builds a second time[2] with updates to the latest versions 
of GemStone so we'll see if our luck holds out ...

Dale

[1] https://travis-ci.org/dalehenrich/Seaside/builds/477576459
[2] https://travis-ci.org/dalehenrich/Seaside/builds/477583354


On 1/9/19 2:50 PM, Dale Henrichs wrote:
>
> 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/8b5b95aa/attachment.html>