Seaside compatibility matrix?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Seaside compatibility matrix?

GLASS mailing list
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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list

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
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list
I did find this issue against Metacello[1], but again I'm not sure that
the number of requests can be reduced without some significant work in
Metacello:(

Dale

[1] https://github.com/Metacello/metacello/issues/495

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
>> [hidden email]
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list
In reply to this post by GLASS mailing list
I see that some of the GS builds work. It appears to be a random process
weighted heavily against success.

I did see the following in the stack report for the original response.
However, what I read in the documentation URL might as well have been in a
foreign language. I read the words but lacked the referents to make them
meaningful.

payload {\n  "message": "API rate limit exceeded for 35.192.187.174. (But
here's the good news: Authenticated requests get a higher rate limit. Check
out the documentation for more details.)",\n  "documentation_url":
"*https://developer.github.com/v3/#rate-limiting*"\n}\n



--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list
In reply to this post by GLASS mailing list

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list
In reply to this post by GLASS mailing list
I didn't look that closely at the actual GemStone versions that are
being tested and the list isn't that far out of wack ... the newer
versions are both less than a month old, so they are being kept up to
date, so my assumption is correct ...

Dale

On 1/9/19 1:44 PM, Dale Henrichs wrote:
> 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:)
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list
In reply to this post by GLASS mailing list
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@.gemtalksystems

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

> Glass@.gemtalksystems

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





--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list
In reply to this post by GLASS mailing list

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list

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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list
In reply to this post by GLASS mailing list

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@.gemtalksystems
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>> _______________________________________________
>> Glass mailing list
>> Glass@.gemtalksystems
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
>
> --
> Sent from: http://forum.world.st/GLASS-f1460844.html
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: Seaside compatibility matrix?

GLASS mailing list
In reply to this post by GLASS mailing list
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
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 <[hidden email]> 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: '<a href="github://GsDevKit/gsApplicationTools:v1.?/repository" class="">github://GsDevKit/gsApplicationTools:v1.?/repository' ];
BaselineOfSeaside3.package/BaselineOfSeaside3.class/instance/baselineadaptors..st:						repository: '<a href="github://GsDevKit/zinc:v2.4.3.?/repository" class="">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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass