[Glass] Seaside compatibility matrix?

Wed Jan 9 16:01:17 PST 2019

PR submitted[1] with tag matching eliminated for GemStone and list 
compatibility list updated to use latest GemStone versions ... travis 
tests still passing[2]:)

Dale

[1] https://github.com/SeasideSt/Seaside/pull/1109
[2] https://travis-ci.org/SeasideSt/Seaside/builds/477595233

On 1/9/19 3:17 PM, Dale Henrichs wrote:
>
> 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/bcba80c3/attachment-0001.html>