[Glass] Seaside compatibility matrix?

Wed Jan 9 16:16:29 PST 2019

On 1/9/19 3:14 PM, Paul DeBruicker via Glass wrote:
> 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.

That's a good question and it isn't clear to me whether or not it is 
possible ... it would be nice to have a better solution than "don't use 
tag matching" in Metacello ... If I'm not mistaken we'd need to modify 
the code to use the env var in the api calls as well ... which would be 
relatively straightforward to do ...

Maybe you and I should get together for pdx smalltalk meeting and next 
Tuesday and `just do it`:)

Dale

>
>
>
>
>
> 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
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass