FWIW, I think exit code definitely belongs in the Heroku API.
That's a longstanding known deficiency. I hope we can fix it
soon, but can't make any promises.
On Sat, Feb 2, 2013 at 9:35 PM, Daniel Doubrovkine dbl...@dblock.org wrote:
I published heroku-commander (https://github.com/dblock/heroku
belongs in the Heroku API.
That's a longstanding known deficiency. I hope we can fix it
soon, but can't make any promises.
On Sat, Feb 2, 2013 at 9:35 PM, Daniel Doubrovkine dbl...@dblock.org
wrote:
I published heroku-commander (https://github.com/dblock/heroku-commander
)
that wraps `heroku
end to make this cleaner and provide for detached processes soon, but as
per Keith no promises.
Kind of an aside, but a couple other things you might check out in case you
were unaware of them:
For direct interactions I would probably recommend the heroku-api gem
instead of Heroku::Client
and which s3
credentials to use. Specifically the config vars are obtained as follows:
base = Heroku::Command::BaseWithApp.**new
config_vars = base.heroku.config_vars(base.**app)
It is my understanding that the heroku gem should no longer be used and
that we should instead use the heroku-api gem
I think Daniels approach is the easiest currently (thanks dB!). Perhaps we
should create a gem for doing looking up the implied app as I'm reticent to
say it belong in heroku-api.
As for config you should be able to use the netrc gem and read the
credentials for 'api.heroku.com' in order
!). Perhaps we
should create a gem for doing looking up the implied app as I'm reticent to
say it belong in heroku-api.
As for config you should be able to use the netrc gem and read the
credentials for 'api.heroku.com' in order to get them.
Hope that helps.
On Tuesday, December 25, 2012 8:12
the heroku-api gem. But as far as I can tell the
heroku-api gem does not automatically handle figuring out the current
heroku app as the heroku gem does. And there is also the issue of
authentication, though that one isn't as much of an issue since I can ask
users to set their HEROKU_API_KEY
that the heroku gem should no longer be used and
that we should instead use the heroku-api gem. But as far as I can tell the
heroku-api gem does not automatically handle figuring out the current
heroku app as the heroku gem does. And there is also the issue of
authentication, though that one
According to the Heroku API docs https://api-docs.heroku.com/,
authentication is done using the User's API Key as password, and a blank
username, through HTTP Basic authentication. However, i found that
authentication works even if I use the account email and password.
I just wanted to check
this:
POST https://api.heroku.com/login
Params: username, password
Response: JSON
{
api_key: abc123
}
Thanks,
Pedro
On Sun, Apr 15, 2012 at 11:39 PM, Arvindh Sukumar arvsuku...@gmail.com wrote:
According to the Heroku API docs, authentication is done using the User's
API Key as password
Well, lo and behold, its working -- on the Aspen stack, no less! The
trick was to keep the code block in the controller or model the action
was being called from.
The only thing not working at this point is adding a worker when one
is already running.
heroku.set_workers(ENV['HEROKU_APP'], +1)
I've been told by Heroku Support that we need to migrate to the Bamboo
stack, upgrade our heroku and rest-client gems to the latest, and this
should work. Thanks to this community's help, I should be able to add
or subtract workers with just a few lines of code!
add_heroku_worker
heroku =
Dammit! I pressed the space bar and inadvertently posted before I was
done typing the message! :/
That code block obviously should have and 'end,' so here it is:
end
There, I feel better now.
On Jan 25, 8:06 am, rubynoob mysmilecent...@gmail.com wrote:
I've been told by Heroku Support that
I may misunderstand how workers get charged on heroku, but from what
I've seen at http://docs.heroku.com/background-jobs and
http://docs.heroku.com/delayed-job, workers get charged $0.05/hr each
no matter how many are running, pro-rated to the second. The maximum
workers per account seems to be
You can start up as many workers (or dynos, for that matter) as you
want through the command line. 24 is just how high the slider goes on
the pricing page.
On Jan 21, 7:52 am, rubynoob mysmilecent...@gmail.com wrote:
I may misunderstand how workers get charged on heroku, but from what
I've
@Pedro:
Here's a link to the stack trace:
https://docs.google.com/document/d/1ntWg7PKgyOnSmAVkURW00O5i_LEDFdRscE78NR-cSfg/edit?hl=enauthkey=CMnLv7UB
We're using RestClient gem version 1.4.2 with the Heroku gem version
1.17.8, FWIW.
@Chris: That is good to know. So it sounds like I don't need
Instead of storing the count of active workers as a heroku config
variable, I decided to create a table in our database to store the
value in.
So now I've got the problem narrowed down to the last line in the
method. Here's the block of code I've now got:
add_heroku_worker
heroku
I've done autoscaling of workers
here: https://github.com/phaza/Heroku-Delayed-Job-Autoscale
It's actually more like auto-shutdown of a single workers, but it works well
in our environment.
--
You received this message because you are subscribed to the Google Groups
Heroku group.
To post to
That was a good call, you definitely don't want to store variables in
config vars. Save if for constants (passwords, urls, etc).
It seems like you might be getting an error due to different versions
of RestClient, not sure though. What version are you using? What's the
stack trace for the
Sorry, I forgot to provide some important details. Someday I won't be
so noobish about all this stuff. :)
I'm using Ruby 1.8.6 on Windows XP, Rails 2.3.2, heroku gem 1.15.1,
and delayed_job gem 2.0.5.
I would have tried ddollar's heroku-autoscale, but it's not ready for
production apps, and
Kudos to you if you were really able to do what you were trying to do. It
looks like something really useful and complicated and I didn't think it
would be possible at all in production since there's only so much you can
fine tune about workers in Heroku.
Congrats!
On Wed, Jan 19, 2011 at 10:37
I'm trying a different approach to autoscaling workers in my heroku
app.
I'm using a custom config variable in my heroku config I've labeled
'WORKER_COUNT', which represents how many workers are running
currently. I've also added HEROKU_USERNAME, HEROKU_PASSWORD, and
HEROKU_APP to my heroku
Hi,
This is in response to the API problems people have been having and
particularly in response to Adam's post at
http://blog.heroku.com/archives/2008/3/3/api_and_external_git_access/.
I hope this is not a redundant post, but it seems people are still
having problems in my brief search of the
On Sun, Mar 30, 2008 at 12:58 PM, Mark S. [EMAIL PROTECTED] wrote:
mbp-mark:~ mark$ heroku clone myapp
Initialized empty Git repository in /Users/mark/myapp/.git/
fatal: '/userapps/11544': unable to chdir or not a git archive
I think I may have fixed this. At the very least, I figured out
On Mar 17, 12:33 pm, shammond42 [EMAIL PROTECTED] wrote:
fatal: '/userapps/4867':unabletochdiror not a git archive
fatal: The remote end hung up unexpectedly
fetch-pack from '[EMAIL PROTECTED]:cavcomcon.git' failed
I'm getting the same problem. List works fine, key is setup (had an
error with
25 matches
Mail list logo
