Seaside compatibility matrix?
Locked
Seaside compatibility matrix?
 
|
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 |
Re: Seaside compatibility matrix?
|
|
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 |
Re: Seaside compatibility matrix?
|
|
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 |
Re: Seaside compatibility matrix?
|
|
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 |
Re: Seaside compatibility matrix?
|
|
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 [2] https://travis-ci.org/dalehenrich/Seaside/builds/477576459 On 1/9/19 1:44 PM, Dale Henrichs wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside compatibility matrix?
|
|
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 |
Re: Seaside compatibility matrix?
|
|
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 |
Re: Seaside compatibility matrix?
|
|
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 [2] https://travis-ci.org/dalehenrich/Seaside/builds/477583354
On 1/9/19 2:50 PM, Dale Henrichs wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside compatibility matrix?
|
|
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:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: Seaside compatibility matrix?
|
|
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 |
Re: Seaside compatibility matrix?
|
|
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
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |