[Glass] Seaside compatibility matrix?

Thu Jan 10 01:54:59 PST 2019

Thanks Dale for the PR which fixes our troubles hitting the GitHub API rate limit.

Nono, I was not letting Gemstone build failures slip through ;)
The issue with GitHub API rate limit was reported here: https://github.com/hpi-swa/smalltalkCI/issues/379 <https://github.com/hpi-swa/smalltalkCI/issues/379>
I had gotten used to the fact that I had to re-trigger the builds on Travis… and  I cannot find a discussion about this anymore, but I had the impression this was not easy to solve. Now, by not using the version tags, this can be solved as well, obviously ;) Thanks for that.

We’re testing against latest bug fix versions of each major Gemstone version. I think this should be fine as I don’t expect major differences raised by bug fix increments.
So yes, I’m updating the list from time to time to take those into account.

cheers!
Johan

> On 10 Jan 2019, at 00:17, Dale Henrichs via Glass <glass at lists.gemtalksystems.com> 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 <https://travis-ci.org/dalehenrich/Seaside/builds/477576459>
> [2] https://travis-ci.org/dalehenrich/Seaside/builds/477583354 <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 <https://developer.github.com/v3/#rate-limiting>
>> [2] https://travis-ci.org/dalehenrich/Seaside/builds/477576459 <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 <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 <https://github.com/SeasideSt/Seaside/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+gemstone>
>>> [3] https://travis-ci.org/GsDevKit/Seaside31/builds <https://travis-ci.org/GsDevKit/Seaside31/builds> 
>>> [4] https://travis-ci.org/GsDevKit/Seaside31/jobs/257457547 <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/ <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 <http://forum.world.st/GLASS-f1460844.html> 
>>>> _______________________________________________ 
>>>> Glass mailing list 
>>>> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com> 
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass <http://lists.gemtalksystems.com/mailman/listinfo/glass> 
> _______________________________________________
> 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/20190110/9704e5fe/attachment-0001.html>