[Glass] Seaside compatibility matrix?

Wed Jan 9 15:14:20 PST 2019

Github's tokens can be permission-less, so all a script/person using it can
do is read public information.  The token can be used as a password in a
basic auth HTTP call.

I don't know if its against github's TOC but could we create a SmalltalkCI
user, create a no-scope a token, and configure the SmalltalkCI scripts to
use it?  

I think through github's API you can create/revoke tokens so the
permission-less tokens could be set to rotate.

GLASS mailing list 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 .gemtalksystems

>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> _______________________________________________
> Glass mailing list

> Glass at .gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Sent from: http://forum.world.st/GLASS-f1460844.html