It sounds like you have a workaround now. But here's some more info on the problem...
The problem is that Google books API provides a very small quota for both anonymous and
authenticated clients. We can't share the same key for development and CI builds as
the quota will not be high enough. Therefore the plan was for CI to use the API key and
for developers to be anonymous. In theory each developer would have their own quota.
However, due to the way Google rate-limits anonymous users, it seems to detect all
developers on the Red Hat VPN as being the same user, and thus using a single quota.
None of this should be a problem as development and staging builds cache requests to the
google books API. So as a developer, you should never need to make a Google Books API call
again, after doing a successful build (unless you clear the cache, of course). However,
there was an issue with this approach, which I though we fixed on Tuesday. However,
I'm still seeing API calls coming from my dev box with a primed cache. I'll report
back once we've investigated further.
Paul.
On 18 Feb 2015, at 21:42, Jason Porter <jporter(a)redhat.com>
wrote:
You'd edit the _config/secrets.yaml.gpg file, but DO NOT COMMIT IT :)
↪ 2015-02-18 Wed 11:34, Markus Eisele <meisele(a)redhat.com>:
>
>
> Paul responded to me directly, he's on pto today. Looks like there's an issue
with the ip address / network you're using the api key from. Starting the build while
not being on VPN solved it.
> Still, seems to be a good idea to have a lightweight prototyping area where I can
just build some slim pages and go ahead with a PR.
> @jason: where do I put in my own api key?
> Thanks for the help so far, M
>
>
>
_______http://blog.eisele.net @myfear
>
>
> -------- Original message --------
> From: Jason Porter <jporter(a)redhat.com>
> Date: 18/02/2015 18:29 (GMT+01:00)
> To: Pete Muir <pmuir(a)redhat.com>, Markus Eisele <meisele(a)redhat.com>,
jbossdeveloper(a)lists.jboss.org
> Subject: Re: [jbossdeveloper] Workaround for Google API Limit?
>
> I doubt you'll have need to do this, but at times I've had to use my Google
API key if I was working on things that required a clean book cache.
> ↪ 2015-02-18 Wed 09:27, Jason Porter <jporter(a)redhat.com>:
>>
>> ----- Pete Muir <pmuir(a)redhat.com> wrote:
>>> I’ll let Paul or Jason respond in detail, but in general we do have a problem
here with local builds.
>>>
>>> If you have a gpg key, I can add you to our password vault, and you can use
our account to increase the rate limit.
>>>
>>> Pete
>>>
>>>> On 18 Feb 2015, at 10:57, Markus Eisele <meisele(a)redhat.com>
wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I am trying to get the local
JBoss.org site setup to contribute some
pages.
>>>> Can't do a rake clean preview because I always run into the Google
User
>>>> Rate
>>>> Limit.
>>>>
>>>>> While processing file
>>>>> An error occurred: User Rate Limit Exceeded. Please sign up
>>>>
>>>> How are you guys locally previewing your changes? Is there a workaround?
>>>> This is not exactly a particular feature of the site I am interested. Can
I
>>>> just
>>>> skip this step somehow?
>>>>
>>>> Thanks for your help!
>>>>
>>>> Cheers,
>>>> M
>>>>
>>>> ___
>>>>
http://blog.eisele.net
>>>>
http://twitter.com/myfear
>>>>
>>>>
>>>> _______________________________________________
>>>> jbossdeveloper mailing list
>>>> jbossdeveloper(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jbossdeveloper
>>>
>>>
>>> _______________________________________________
>>> jbossdeveloper mailing list
>>> jbossdeveloper(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbossdeveloper
_______________________________________________
jbossdeveloper mailing list
jbossdeveloper(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbossdeveloper
Paul.
--
Paul Robinson
JBoss Developer Team Lead (
www.jboss.org)
Free/busy info:
https://www.google.com/calendar/embed?src=probinso%40redhat.com&ctz=E...
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors:Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Paul Hickey
(Ireland)