Here's a trace: http://pastie.org/5443907

I removed bundle/gemfile.lock and rebundled, now receiving this error.

Sometimes while running the tests for the heroku buildpack I get this error from heroku-api gem while executing post_app:

  Heroku::API::Errors::RequestFailed:
       Expected(202) <=> Actual(422 Unprocessable Entity)
     # /Users/schneems/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/excon-0.25.3/lib/excon/middlewares/expects.rb:6:in `response_call'
     # /Users/schneems/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/excon-0.25.3/lib/excon/middlewares/response_parser.rb:8:in `response_call'
     # /Users/schneems/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/excon-0.25.3/lib/excon/connection.rb:349:in `response'
     # /Users/schneems/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/excon-0.25.3/lib/excon/connection.rb:247:in `request'
     # /Users/schneems/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/heroku-api-0.3.15/lib/heroku/api.rb:76:in `request'
     # /Users/schneems/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/heroku-api-0.3.15/lib/heroku/api/apps.rb:42:in `post_app'

There was an internal thread in API about this error, but not much came of it. Is there an easy way to grab the request ID or get more info from the request that failed?

I've seen this on Travis, on other people's machines and on mine. When it happens, it stays for awhile, then goes away for hours, days, weeks at a time. Using version 0.3.15

Why Heroku::API.post_login is not a CLASS method? Why it is a INSTANCE method?

When not knowing API Key, have to create an instance TWICE.

instance1 = Heroku::API.new
api_key = instance1.post_login('MYACCOUNT', 'MYPASSWORD')
instance2= Heroku::API.new(api_key)

If Heroku::API.post_login is a class method, useless instance generation can be lost.

When using a client which is not authorized (see #53)
I get an error:

Heroku::API::Errors::Forbidden: Expected(200) <=> Actual(403 Forbidden)

This error causes my client to dump the password in the clear (I put in the XXXXXX)

=>"/apps/myappname/addons", :port=>"443", :query=>nil, :scheme=>"https", :user=>nil, :password=>"XXXXXXX", :username=>"XXXXXXX", :expects=>200, :method=>:get, :retries_remaining=>4}

Config vars can take only string values. Until recently
this wasn't enforced by the server.

It would be nice if the client could check for this before
even sending an api request.

Currently it just converts everything directly to json:
https://github.com/heroku/heroku.rb/blob/master/lib/heroku/api/config_vars.rb

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can image, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

I'd like to use heroku labs api

How can I get the commit hash of the last release/deployment?

It seems impossible to get the last release without getting all the releases and traversing them. This is not great when you have hundreds of releases.

For some reason, running get_ssl_endpoints against an app with no endpoints added returns a HTTP 403 which is misleading.

I am authorised, there's just no endpoints. Surely an empty array or something needs to be returned here?

I've found that if, for some reason, app is a blank string, heroku.rb accepts it as a valid param and tries to make requests to the Heroku API.

This leads to a 404 error, which is generally only noticeable if you see that the URL that is 404'ing is something similar to /app//domains etc.

I'm thinking that this should be caught somehow and made into a more relevant error. Essentially an app name validation.

Happy to have a stab at this, as long as I know the approach (and the issue) is sound.

There are a few places where Excon is referenced directly in the heroku gem. I'd like to have no knowledge of the heroku.rb internals if possible.

More info: https://github.com/heroku/dashboard/issues/1623

Any objections, @geemus ?

My use case is that I want to get the Delayed::Job.count remotely in a script. I know the old Heroku gem is deprecated, so I'm trying to use this new (nice & simple, btw!) gem to get things done, and haven't quite figured out this last step.

I'd like to propose to make some corrections to current heroku.rb implementation.

It's how I think it should behave:

heroku = Heroku::API.new
app = heroku.apps.first

app.addons.add 'sendgrid:starter' # true
app.addons.delete 'mongolab' # true

app.maintenance # false
app.maintenance = true
app.maintenance # true
app.maintenance = false
app.maintenance! #true

app.collaborators # [#<Collaborator email: "[email protected]">]

app.config_vars.add 'RUBY_VERSION', '1.9.3-p125'

Current heroku.rb looks more like heroku.py. I'd like it to be more Ruby-ish.

irb(main):001:0> require 'heroku-api'
=> true
irb(main):002:0> api = Heroku::API.new(:api_key => "[redacted]")
irb(main):005:0> api.get_config_vars "i-do-not-exist"
Heroku::API::Errors::NotFound: Expected(200) <=> Actual(404 Not Found)
  request => {:connect_timeout=>60, :headers=>{"Accept"=>"application/json", "Accept-Encoding"=>"gzip", "Authorization"=>"[redacted]", "User-Agent"=>"heroku-rb/0.3.4", "X-Ruby-Version"=>"1.9.3", "X-Ruby-Platform"=>"x86_64-linux", "Host"=>"api.heroku.com:443"}, :instrumentor_name=>"excon", :mock=>false, :nonblock=>false, :read_timeout=>60, :retry_limit=>4, :ssl_ca_file=>"/app/vendor/bundle/ruby/1.9.1/gems/excon-0.16.2/data/cacert.pem", :ssl_verify_peer=>true, :write_timeout=>60, :host=>"api.heroku.com", :path=>"/apps/i-do-not-exist/config_vars", :port=>"443", :query=>nil, :scheme=>"https", :expects=>200, :method=>:get}
  response => #<Excon::Response:0x000000030eac60 @body="App not found.", @headers={"Cache-Control"=>"no-cache", "Content-Type"=>"application/json; charset=utf-8", "Date"=>"Thu, 06 Sep 2012 00:45:50 GMT", "Server"=>"nginx/1.0.14", "Status"=>"404 Not Found", "Strict-Transport-Security"=>"max-age=500", "X-RateLimit-Limit"=>"5000", "X-RateLimit-Remaining"=>"4998", "X-RateLimit-Reset"=>"1346892392", "X-Runtime"=>"43", "Content-Length"=>"14", "Connection"=>"keep-alive"}, @status=404>

The response claims the Content-Type is JSON, but it's not. Other errors (even other 404s) return a JSON object:

@body="{\"error\":\"blah blah blah, i am some error\"}"

I need to include heroku-api as a dependency in heroku_san's gemspec, but I need to get the latest and greatest. Would you bump the version number?

Thx!
Ken

Ref heroku/legacy-cli#508

I currently have the heroku gem in a project's bundle because it has Heroku::Auth.api which makes it really easy to get a ready-to-use Heroku::API instance. I don't have to worry about netrc and other stuff.

It would be nice if heroku.rb itself or another gem outside the main CLI gem provided what is in Heroku::Auth so I could easily get a Heroku::API instance without bringing in the entire CLI.

It's possible this is complicated by plugins that change the auth process.

Looks like we can scale workers using post_ps_scale, but there doesn't seem to be a method to count the number of workers running right now. Did I miss it?

Heroku::API is missing the top level /resources endpoint.

I may get around to submitting a patch, but I got my code working with just #request(path: '/resources', method: :get, expects: 200).body so I may forget to do it, so I'm opening this ticket now while thinking about it.

heroku = Heroku::API.new(:api_key => API_KEY)
heroku.put_formation(APP_NAME, 'web' => 'Free')
heroku.post_ps_scale(APP_NAME, 'web'   , 1)

Error: body: "{\"id\":\"invalid_params\",\"error\":\"Requested type Free is not available in this dyno type.\"}"

Why that? I can't change my dyno size with API?

The DELETE /apps/:app/collaborators/:email call fails if the email has special characters (e.g. +) and needs to be URL encoded.

Is there a way to differentiate config variables, addon/heroku/app defined?

Here my use case for this:
List of config variables that are source controlled and needs to be applied during deploy. This works when I need to update/add config variables. But when I delete I need to some how get a delta, without mistakenly removing addon and heroku defined ones.

OkJson has decoding issues, is not performant, etc.

The gem is almost perfect, but at least you could provide an endpoint to retrieve the list of backups, able to restore a db from a backup_id, or at least return a url for the latest backup (or given a backup_id)..
If there's a workaround to this, please let me know. Thanks a lot!

Getting the error The following keys are invalid: :username
when initializing

Heroku::API.new(:username => ENV['HEROKU_USER'], :password => ENV['HEROKU_PASSWORD']) 
The following keys are invalid: :username
The following keys are invalid: :username

Please, pretty please add a way to filter out log sources.
Example:

#existing syntax
heroku logs -s JUST_THIS_ONE
#new option
heroku logs -S EXCEPT_THIS_ONE

I routinely tail the logs, and while I already filter out some unwanted bits, the Postgres source often fills up the logs with huge SQL autogenerated queries, which span multiple lines and thus can't be filtered out.
Example:

app[heroku-postgres] BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH 
BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH
BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH BLAH

and so on.
I can filter out "app[heroku-postgres]", but not lines 2 and on.

I reckon this requires support in heroku API, but I couldn't find the new platform API in Github.
If it exists as a public repo, then I'll gladly do the work myself and make a pull request.

The put_workers call doesn't work with Cedar apps. I get a response that says

Heroku::API::Errors::RequestFailed: Expected(200) <=> Actual(422 Unprocessable Entity)

@body="{\"error\":\"For Cedar apps, use `heroku scale worker=1`\"}"

There doesn't seem to be any way to call that at the moment

Is there currently a way to set this value using this library?

(from heroku/legacy-cli#606)

This error should come up to heroku as something a bit nicer I think.

heroku-api (0.3.5)

Without Mock

h = Heroku::API.new api_key: ENV['HEROKU_API_KEY']
h.get_domains "my-app"
# successfully returns list of domains

With Mock

h = Heroku::API.new api_key: ENV['HEROKU_API_KEY'], mock: true
h.get_domains "my-app"
=> Heroku::API::Errors::NotFound: Expected(200) <=> Actual(404 Not Found)
response => #<Excon::Response:0x007fd5158a3148 @body="App not found.", @headers={}, @status=404>

Or at the very least it is not documented

https://api-docs.heroku.com/apps#POST/apps

I just updated to version 0.3.9 of your gem and after a debugging session I finally discovered that from now on you mock requests when running tests.

Could you at least output a warning saying that requests are mocked? It was really hard for me to figure out what’s actually happening.

In my opinion even better would be to make mocking optional. It shouldn’t be a problem for anyone to define that behavior in their spec_helper.rb or wherever they need it.

Thanks a lot!

Update: It works when I use :mock => false. Sorry for opening this issue unnecessarily, It didn't work when I set MOCK=false.

I have one app called obscure-basin-1623 on Heroku. When using the gem heroku-api 0.3.7, this test fails:

def test_apps
    api = Heroku::API.new( :api_key => ENV['HEROKU_API_KEY'], :mock => ENV['MOCK'] )
    apps = api.get_apps()
    assert_not_nil apps
    assert_equal apps.status, 200
    puts apps.status
    assert_not_nil apps.body
    assert_operator apps.body.length, :>, 0
    puts apps.body.to_s
end

Output:

Expected 0 to be > 0.

Note that the following command also fails (probably because the app just can't be found):

 api.get_ps( "obscure-basin-1623" )

Output:

Heroku::API::Errors::NotFound: App not found.

My environment variables are set correctly (I use foreman for managing them), the API gem authenticates successfully. It works fine over the web interface, thus I suspect the error being in the heroku-api gem. I would be glad to provide further information if necessary.

Bundle mock data is outdated, could a new version be cut with updated data?

Is this gem talking to that API or is it talking to an older API and will eventually be using the new one when its GA?

Is there plans to adding the forking commands to the heroku.rb client? Or is that exclusively a command for the CLI?

When I use the following command on the console, it creates the Heroku::Api object

heroku = Heroku::API.new username: ENV['HEROKU_USER'], password: ENV['HEROKU_PASSWORD'], mock: !Rails.env.prod?

But this same command fails in the rspec tests and it generates

Heroku::API::Errors::NotFound:
Expected(200) <=> Actual(404 Not Found)

When I investigated further I found that

In console, the excon connection object that getting generated in development(console) is different from the test environment

In console:

#<Excon::Connection:7f9a71607530 @data={:chunk_size=>1048576, :connect_timeout=>60, :debug_request=>false, 
:debug_response=>false, :headers=>{"Accept"=>"application/json", "Accept-Encoding"=>"gzip", "User-Agent"=>"heroku-rb/0.3.15", "X-Ruby-Version"=>"2.0.0", "X-Ruby-Platform"=>"x86_64-darwin11.4.2"}, :idempotent=>false, 
:instrumentor_name=>"excon", :middlewares=>[Excon::Middleware::ResponseParser, Excon::Middleware::Expects, 
Excon::Middleware::Idempotent, Excon::Middleware::Instrumentor, Excon::Middleware::Mock], :mock=>true, 
:nonblock=>false, :omit_default_port=>false, :read_timeout=>60, :retry_limit=>4, :ssl_verify_peer=>true, 
:tcp_nodelay=>false, :uri_parser=>URI, :write_timeout=>60, :host=>"api.heroku.com", :path=>"", :port=>"443", 
:query=>nil, :scheme=>"https", :user=>nil, :password=>nil} @socket_key="https://api.heroku.com:443">

In Tests

#<Excon::Connection:7ff5dd0c3ac0 @data={:chunk_size=>1048576, :connect_timeout=>60, :debug_request=>false, 
:debug_response=>false, :headers=>{"Accept"=>"application/json", "Accept-Encoding"=>"gzip", "User-Agent"=>
"heroku-rb/0.3.15", "X-Ruby-Version"=>"2.0.0", "X-Ruby-Platform"=>"x86_64-darwin11.4.2"}, :idempotent=>false, 
:instrumentor_name=>"excon", :middlewares=>[Excon::Middleware::ResponseParser, Excon::Middleware::Expects, 
Excon::Middleware::Idempotent, Excon::Middleware::Instrumentor, Excon::Middleware::Mock], :mock=>true, 
:nonblock=>false, :omit_default_port=>false, :read_timeout=>60, :retry_limit=>4, :ssl_verify_peer=>true, 
:tcp_nodelay=>false, :uri_parser=>URI, :write_timeout=>60, :host=>"api.heroku.com", :path=>"", :port=>"443", 
:query=>nil, :scheme=>"https", :user=>nil, :password=>nil, :__construction_args=>{:host=>"api.heroku.com", 
:path=>"", :port=>"443", :query=>nil, :scheme=>"https", :user=>nil, :password=>nil, :headers=>{"Accept"=>
"application/json", "Accept-Encoding"=>"gzip", "User-Agent"=>"heroku-rb/0.3.15", "X-Ruby-Version"=>"2.0.0", "X-
Ruby-Platform"=>"x86_64-darwin11.4.2"}, :nonblock=>false, :mock=>true}} @socket_key="https://api.heroku.com:443">

I see that the second object has an additional key value :__construction_args

I am not sure weather this key value is creating an issue.

Currently, timeouts are caught by rescue Excon::Errors::Error, but a Excon::Errors::Timeout doesn't have a #response method causing undefined method 'response' for #<Excon::Errors::Timeout...

Proposed change:

def request(params, &block)
  begin
    response = @connection.request(params, &block)
  rescue Excon::Errors::HTTPStatusError => error # Only HTTPStatusError has #response
    ...
  end # Raise on everything else

The Heroku Legacy API and API docs links in the README both end up getting redirected to https://devcenter.heroku.com/categories/platform-api

:{

We currently use the heroku-api gem for continuous deployment from Travis CI and have our users asking for the ability to run pgbackups:capture before deploying. I have not found a way to do this short of installing the heroku toolbelt. :/

Maybe I'm just missing something.

I'm using the post_ssl_endpoint, and I'm getting the following error:
`Heroku::API::Errors::ErrorWithResponse: Expected(200) <=> Actual(201 Created)``
As you can see with the response code it's uploading correctly, but the gem is expecting a 200 response code.

Could someone help educate a newb on how to extract the exception message from a call like heroku.add_domain?

I am getting: "Message for the log file!" and a big nasty string. Any help with a ruby example would be appreciated

Thank you

Calls such as heroku.get_apps return an excon response instead of the stated "array of apps". Should we update the docs to be heroku.get_apps.body or do a minor version rev and return something else from calls like get_apps

https://github.com/heroku/heroku.rb/blob/master/lib/heroku/api.rb#L90-91

Why so?