Code Monkey home page Code Monkey logo

platform-api's Introduction

Platform API

Ruby HTTP client for the Heroku API.

NOTE: v2.0.0 fixed a long-standing issue with duplicated link titles, which may break things if you were relying on the now-renamed methods.

Installation

Add this line to your application's Gemfile:

gem 'platform-api'

And then execute:

bundle

Or install it yourself as:

gem install platform-api

API documentation

Jump right to the API documentation for the nitty gritty details.

Usage guide

The best place to start using the Heroku API is the Platform API Reference. It has detailed descriptions of the HTTP API, including general information about authentication, caching, object identifiers, rate limits, etc. It also includes detailed information about each supported resource and the actions available for them.

The table of contents lists all the resources that are supported, such as App, Add-on, Config Vars, Formation, etc. Each resource includes detailed information about the support actions. For example, the Formation resource has Info, List, Batch update, and Update actions.

Resources and their related actions are available as methods on the client. When the URL for an action includes parameters they're passed as arguments to the method. When the request expects a request payload it's passed as a Hash in the final argument to the method.

For example, to get information about the web formation on the sushi app you'd invoke heroku.formation.info('sushi', 'web') and it would return a Ruby object that matches the one given in the response example.

The API documentation contains a description of all available resources and methods.

Handling errors

The client uses Excon under the hood and raises Excon::Error exceptions when errors occur. You can catch specific Excon error types if you want.

A real world example

Let's go through an example of creating an app and using the API to work with it. The first thing you need is a client setup with an OAuth token. You can create an OAuth token using the heroku-oauth toolbelt plugin:

$ heroku plugins:install heroku-cli-oauth
$ heroku authorizations:create -d "Platform API example token"
Created OAuth authorization.
  ID:          2f01aac0-e9d3-4773-af4e-3e510aa006ca
  Description: Platform API example token
  Scope:       global
  Token:       e7dd6ad7-3c6a-411e-a2be-c9fe52ac7ed2

Use the Token value when instantiating a client:

require 'platform-api'
heroku = PlatformAPI.connect_oauth('e7dd6ad7-3c6a-411e-a2be-c9fe52ac7ed2')

The OAuth article has more information about OAuth tokens, including how to create tokens with specific scopes.

Now let's create an app:

heroku.app.create({})
=> {"id"=>22979756,
    "name"=>"floating-retreat-4255",
    "dynos"=>0,
    "workers"=>0,
    "repo_size"=>nil,
    "slug_size"=>nil,
    "stack"=>"cedar",
    "requested_stack"=>nil,
    "create_status"=>"complete",
    "repo_migrate_status"=>"complete",
    "owner_delinquent"=>false,
    "owner_email"=>"[email protected]",
    "owner_name"=>nil,
    "domain_name"=>
     {"id"=>nil,
      "app_id"=>22979756,
      "domain"=>"floating-retreat-4255.herokuapp.com",
      "base_domain"=>"herokuapp.com",
      "created_at"=>nil,
      "default"=>true,
      "updated_at"=>nil},
    "web_url"=>"http://floating-retreat-4255.herokuapp.com/",
    "git_url"=>"[email protected]:floating-retreat-4255.git",
    "buildpack_provided_description"=>nil,
    "region"=>"us",
    "created_at"=>"2014/03/12 16:44:09 -0700",
    "archived_at"=>nil,
    "released_at"=>"2014/03/12 16:44:10 -0700",
    "updated_at"=>"2014/03/12 16:44:10 -0700"}

We can read the same information back with the info method.

heroku.app.info('floating-retreat-4255')
=> {"id"=>22979756,
    "name"=>"floating-retreat-4255",
    "dynos"=>0,
    "workers"=>0,
    "repo_size"=>nil,
    "slug_size"=>nil,
    "stack"=>"cedar",
    "requested_stack"=>nil,
    "create_status"=>"complete",
    "repo_migrate_status"=>"complete",
    "owner_delinquent"=>false,
    "owner_email"=>"[email protected]",
    "owner_name"=>nil,
    "domain_name"=>
     {"id"=>nil,
      "app_id"=>22979756,
      "domain"=>"floating-retreat-4255.herokuapp.com",
      "base_domain"=>"herokuapp.com",
      "created_at"=>nil,
      "default"=>true,
      "updated_at"=>nil},
    "web_url"=>"http://floating-retreat-4255.herokuapp.com/",
    "git_url"=>"[email protected]:floating-retreat-4255.git",
    "buildpack_provided_description"=>nil,
    "region"=>"us",
    "created_at"=>"2014/03/12 16:44:09 -0700",
    "archived_at"=>nil,
    "released_at"=>"2014/03/12 16:44:12 -0700",
    "updated_at"=>"2014/03/12 16:44:12 -0700"}

Let's add a Heroku PostgreSQL database to our app now:

heroku.addon.create('floating-retreat-4255', {'plan' => 'heroku-postgresql:hobby-dev'})
=> {"config_vars"=>["HEROKU_POSTGRESQL_COBALT_URL"],
    "created_at"=>"2014-03-13T00:28:55Z",
    "id"=>"79a0c826-06be-4dcd-8bb5-f2c1b1bc2beb",
    "name"=>"heroku-postgresql-cobalt",
    "plan"=>
     {"id"=>"95a1ce4c-c651-45dc-aaee-79b4603e76b7",
      "name"=>"heroku-postgresql:dev"},
    "provider_id"=>"[email protected]",
    "updated_at"=>"2014-03-13T00:28:55Z"}

Excellent! That will have added a config var which we can now see:

heroku.config_var.info_for_app('floating-retreat-4255')
=> {"HEROKU_POSTGRESQL_COBALT_URL"=>"postgres://<redacted>"}

And there we go, we have the config var. Let's set an additional config var, which will also demonstrate how to make a request that needs a payload:

heroku.config_var.update('floating-retreat-4255', {'MYAPP' => 'ROCKS'})
=> {"HEROKU_POSTGRESQL_COBALT_URL"=>"postgres://<redacted>",
    "MYAPP"=>"ROCKS"}

As you can see, any action that needs a request body takes it as a plain Ruby object, as the final parameter of the method call.

Using the same principle you can even pass in a specific version of PostgreSQL at the time of creation:

heroku.addon.create('floating-retreat-4255', {'plan' => 'heroku-postgresql:dev', 'config' => {'version' => '9.4'})

Make sure to use the correct version. If the version is incorrect or unsupported, it will just error out.

Let's continue by deploying a sample app. We'll use the Geosockets example app:

$ git clone https://github.com/heroku-examples/geosockets.git
Cloning into 'geosockets'...
remote: Reusing existing pack: 489, done.
remote: Total 489 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (489/489), 1.95 MiB | 1.14 MiB/s, done.
Resolving deltas: 100% (244/244), done.
Checking connectivity... done.
$ cd geosockets
$ git remote add heroku [email protected]:floating-retreat-4255.git
$ heroku labs:enable websockets
$ heroku addons:add openredis:micro # $10/month
Adding openredis:micro on floating-retreat-4255... done, v10 ($10/mo)
Use `heroku addons:docs openredis` to view documentation.
$ git push heroku master
Initializing repository, done.
Counting objects: 489, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (229/229), done.
Writing objects: 100% (489/489), 1.95 MiB | 243.00 KiB/s, done.
Total 489 (delta 244), reused 489 (delta 244)
8< snip 8<

We can now use the API to see our web process running:

heroku.formation.list('floating-retreat-4255')
=> [{"command"=>"coffee index.coffee",
     "created_at"=>"2014-03-13T04:13:37Z",
     "id"=>"f682b260-8089-4e18-b792-688cc02bf923",
     "type"=>"web",
     "quantity"=>1,
     "size"=>"Standard-1X",
     "updated_at"=>"2014-03-13T04:13:37Z"}]

Let's change web process to run on a 2X dyno:

heroku.formation.batch_update('floating-retreat-4255',
                              {"updates" => [{"process" => "web",
                                              "quantity" => 1,
                                              "size" => "Standard-2X"}]})
=> [{"command"=>"coffee index.coffee",
     "created_at"=>"2014-03-13T04:13:37Z",
     "id"=>"f682b260-8089-4e18-b792-688cc02bf923",
     "type"=>"web",
     "quantity"=>1,
     "size"=>"Standard-2X",
     "updated_at"=>"2014-03-13T04:22:15Z"}]

We could have included a number of different kinds of processes in the last command. We can use the singular update action to modify a single formation type:

heroku.formation.update('floating-retreat-4255', 'web', {"size" => "Standard-1X"})
=> {"command"=>"coffee index.coffee",
    "created_at"=>"2014-03-13T04:13:37Z",
    "id"=>"f682b260-8089-4e18-b792-688cc02bf923",
    "type"=>"web",
    "quantity"=>1,
    "size"=>"Standard-1X",
    "updated_at"=>"2014-03-13T04:24:46Z"}

Hopefully this has given you a taste of how the client works. If you have questions please feel free to file issues.

Debugging

Sometimes it helps to see more information about the requests flying by. You can start your program or an irb session with the EXCON_DEBUG=1 environment variable to cause request and response data to be written to STDERR.

Passing custom headers

The various connect methods take an options hash that you can use to include custom headers to include with every request:

client = PlatformAPI.connect('my-api-key', default_headers: {'Foo' => 'Bar'})

Using a custom cache

By default, the platform-api will cache data in ~/.heroics/platform-api. Use a different caching by passing in the Moneta instance you want to use:

client = PlatformAPI.connect('my-api-key', cache: Moneta.new(:Memory))

Connecting to a different host

Connect to a different host by passing a url option:

client = PlatformAPI.connect('my-api-key', url: 'https://api.example.com')

Rate throttling

Rate throttling capability is inclued in PlatformAPI v2.3.0, but is disabled by default. The following section describes the behavior of the PlatformAPI gem v3.0.0+. To enable rate throttling logic, upgrade to the latest released version.

By default client requests from this library will respect Heroku's rate-limiting. The client can make as many requests as possible until Heroku's server says that it has gone over. Once a request has been rate-limited the client will sleep and then retry the request again. This process will repeat until the request is successful.

Once a single request has been rate-limited, the client will auto-tune a sleep value so that future requests are less likely to be rate-limited by the server.

Rate throttle strategies are provided by the Rate Throttle Client gem. By default the RateThrottleClient::ExponentialIncreaseProportionalRemainingDecrease strategy is used.

To disable this retry-and-sleep behavior you can change the rate throttling strategy to any object that responds to call and yields to a block:

PlatformAPI.rate_throttle = ->(&block) { block.call }

# or

PlatformAPI.rate_throttle = RateThrottleClient::Null.new

By default rate throttling will log to STDOUT when the sleep/retry behavior is triggered:

RateThrottleClient: sleep_for=0.8

To add your own custom logging, for example to Librato or Honeycomb, you can configure logging by providing an object that responds to call and takes one argument:

PlatformAPI.rate_throttle.log = ->(info) {
  # Your logic here

  puts info.sleep_for
  puts info.request
}

Building and releasing

Generate a new client

Generate a new client from the Heroku Platform API JSON schema:

rake build

Remember to commit and push the changes to Github.

Release a new gem

  • This project follows semver from version 1.0.0. Please be sure to keep this in mind if you're the project maintainer.
  • Be sure to run the very basic acceptance rspecs. The rspecs will attempt to parse your oauth token for api.heroku.com from your .netrc. You can optionally use the OAUTH_TOKEN and ACCOUNT_EMAIL environment variables. They don't mutate anything but they might in the future.
  • Bump the version in lib/platform-api/version.rb
  • bundle install to update Gemfile.lock
  • `git commit -m 'vX.Y.Z' to stage the version and Gemfile.lock changes
  • rake release to push git changes and to release to Rubygems

Building API documentation

Build documentation with:

rake yard

And then visit doc/index.html to read it. Alternately, build and publish it to Github Pages in one step with:

rake publish_docs

You can see it live on Github Pages.

Contributing

  1. Fork the repository.
  2. Create your feature branch: git checkout -b my-new-feature
  3. Commit your changes: git commit -am 'Add some feature'
  4. Push to the branch: git push origin my-new-feature
  5. Create new pull request.

Testing

The tests make live network calls so you'll need to ensure that you're logged into your Heroku account. You'll also need an application that uses a set of Heroku's features, if you don't have one you can create one. E.g.

$ git clone https://github.com/heroku/ruby-getting-started.git
$ cd ruby-getting-started/
$ heroku create <memorable-name-here>
$ heroku webhooks:add -i api:dyno -l notify -u https://example.com/hooks
$ git push heroku master

Now you can specify your app name while you run tests:

$ TEST_APP_NAME="<memorable-name-here>" rspec ./spec

If you run tests without specifying a TEST_APP_NAME then an app will be created and deployed under your user account.

platform-api's People

Contributors

10io avatar andhapp avatar atmartin avatar austinbgibbons avatar calebhearth avatar conroywhitney avatar djcp avatar dmcinnes avatar geemus avatar gudmundur avatar holoiii avatar jkakar avatar jvinil05 avatar martincai8 avatar mathias avatar michaelrkn avatar paguilar-sfdc avatar paul avatar schneems avatar svc-scm avatar technicalpickles avatar timminkov avatar timolehto avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

platform-api's Issues

How to specify an addon's version?

Hey,

I am using the API to create add-ons and that works fine. However, I'd like to specify a version for the addon to be installed on my account. For example: Heroku PostgreSql, I'd like to install postgres 9.4.9 as opposed to the latest.

How can I achieve that in the API?

I couldn't see any examples or anything in the code related to this. May be it's not possible but would like to know before I start exploring other options.

Thanks.

Issue with domain#create

I'm hoping I'm just doing something wrong here. When calling heroku.domain.create(), I'm getting a 400 error.

To start, here's what works.

irb(main):003:0> heroku.domain.list('[email protected]')
=> [{"acm_status"=>nil, ...}]

irb(main):004:0> heroku.domain.delete('[email protected]', '*.example.com')
=> {"acm_status"=>nil, ...}
# I was able to confirm that this does delete the domain

And here's what doesn't.

irb(main):005:0> heroku.domain.create('UUID_HERE', '*.example.com')
Excon::Error::NotFound: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(404 Not Found)

irb(main):006:0> heroku.domain.create('my-app-name', '*.example.com')
Excon::Error::BadRequest: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(400 Bad Request)

irb(main):007:0> heroku.domain.create('[email protected]', '*.example.com')
Excon::Error::BadRequest: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(400 Bad Request)

Our API docs suggest that either the UUID or app name should suffice (even the heroku_id works in the delete example above!), which makes me wonder why using the UUID returns a 404 while the app name example returns a 400.

Am I just doing something dumb? It seems pretty straightforward.

Update: in a humbling turn of events, the alternate error I was receiving above for the UUID method was indeed valid; I somehow had the wrong UUID for the app. correcting this yields the same 400 BadRequest error the other two commands were returning.

Using EXCON_DEBUG returns the following (assuming the important bits, omitting others - let me know if you need something else):

  :body                => "\"*.example.com\""
  :host                => "api.heroku.com"
  :hostname            => "api.heroku.com"
  :method              => :post
  :path                => "/apps/UUID_HERE/domains"

Delay in getting updated dyno list

I have several detached run dynos:

> heroku ps 
...
=== run: one-off processes
run.1650 (1X): up 2014/05/18 18:31:30 (~ 22m ago): `bin/console`
run.5513 (PX): up 2014/05/18 18:31:11 (~ 22m ago): `bundle exec sidekiq -q tools -g worker_1d006aa1_c66a_4331_a197_23217d4ec7b3 -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1`
run.8605 (PX): up 2014/05/18 18:31:13 (~ 22m ago): `bundle exec sidekiq -q tools -g worker_dadd7d65_07ee_487d_96c4_b0ffbcb39248 -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1`
run.9531 (PX): up 2014/05/18 18:31:12 (~ 22m ago): `bundle exec sidekiq -q tools -g worker_37d3e8ac_aedd_4048_a9aa_e92bc3e09a1b -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1`

In console, I run:

irb(main):040:0> puts PlatformAPI.connect_oauth(Config.heroku_platform_api_token).dyno.list(Config.heroku_app_name).map{|v| "%s: %s" % [v['name'],v['command']]}
web.1: bundle exec puma --config config/puma.rb config.ru
run.5513: bundle exec sidekiq -q tools -g worker_1d006aa1_c66a_4331_a197_23217d4ec7b3 -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1
run.9531: bundle exec sidekiq -q tools -g worker_37d3e8ac_aedd_4048_a9aa_e92bc3e09a1b -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1
run.8605: bundle exec sidekiq -q tools -g worker_dadd7d65_07ee_487d_96c4_b0ffbcb39248 -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1
run.1650: bin/console
=> nil

I then kill one detached run worker: heroku ps:stop run.5513 which works according to heroku ps, but the platform-api gem continues to show stale data for hours.

ps:

> heroku ps 
...
=== run: one-off processes
run.1650 (1X): up 2014/05/18 18:31:29 (~ 29m ago): `bin/console`
run.8605 (PX): up 2014/05/18 18:31:12 (~ 30m ago): `bundle exec sidekiq -q tools -g worker_dadd7d65_07ee_487d_96c4_b0ffbcb39248 -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1`
run.9531 (PX): up 2014/05/18 18:31:11 (~ 30m ago): `bundle exec sidekiq -q tools -g worker_37d3e8ac_aedd_4048_a9aa_e92bc3e09a1b -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1`

console:

irb(main):041:0> puts PlatformAPI.connect_oauth(Config.heroku_platform_api_token).dyno.list(Config.heroku_app_name).map{|v| "%s: %s" % [v['name'],v['command']]}
web.1: bundle exec puma --config config/puma.rb config.ru
run.5513: bundle exec sidekiq -q tools -g worker_1d006aa1_c66a_4331_a197_23217d4ec7b3 -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1
run.9531: bundle exec sidekiq -q tools -g worker_37d3e8ac_aedd_4048_a9aa_e92bc3e09a1b -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1
run.8605: bundle exec sidekiq -q tools -g worker_dadd7d65_07ee_487d_96c4_b0ffbcb39248 -i ${DYNO:-1} -r ./lib/sidekiq_wrapper.rb -c 1
run.1650: bin/console
=> nil

Do I need to reinitialize the client or somehow force a reconnect to get up to date info?

Docs are wrong (or outdated)

In the docs we get an example that looks like this:

heroku.app.info('floating-retreat-4255')
=> {"id"=>22979756,
    "name"=>"floating-retreat-4255",
    "dynos"=>0,
    "workers"=>0,
    "repo_size"=>nil,
    "slug_size"=>nil,
    "stack"=>"cedar",
    "requested_stack"=>nil,
    "create_status"=>"complete",
    "repo_migrate_status"=>"complete",
    "owner_delinquent"=>false,
    "owner_email"=>"[email protected]",
    "owner_name"=>nil,
    "domain_name"=>
     {"id"=>nil,
      "app_id"=>22979756,
      "domain"=>"floating-retreat-4255.herokuapp.com",
      "base_domain"=>"herokuapp.com",
      "created_at"=>nil,
      "default"=>true,
      "updated_at"=>nil},
    "web_url"=>"http://floating-retreat-4255.herokuapp.com/",
    "git_url"=>"[email protected]:floating-retreat-4255.git",
    "buildpack_provided_description"=>nil,
    "region"=>"us",
    "created_at"=>"2014/03/12 16:44:09 -0700",
    "archived_at"=>nil,
    "released_at"=>"2014/03/12 16:44:12 -0700",
    "updated_at"=>"2014/03/12 16:44:12 -0700"}

However when I actually connected to the API I found that info did not return dynos / workers. Looking that the attributes here I don't see them listed either.

I'm happy to submit a patch I just wanted to make sure I'm not missing something first :) Was a bit of a bummer to find out later.

platform-api incompatible with heroics 0.0.22

I was just going through an app to update dependencies and think I've found an incompatibility. platform-api depends on ~> 0.0.21 of heroics, which just today released 0.0.22. Running bundle update in the project updates the heroics dependency to 0.0.22 and keeps bundler from being able to load gems:

# Gemfile.lock
    heroics (0.0.22)
      erubis (~> 2.0)
      excon
      multi_json (>= 1.9.2)

    ...
    platform-api (1.0.1)
      heroics (~> 0.0.21)
      moneta (~> 0.8.1)
โžœ  app git:(gem-update-2017-05) โœ— bundle exec rake
rake aborted!
Bundler::GemRequireError: There was an error while trying to load the gem 'platform-api'.
Gem Load Error is: Duplicate link names 'info', 'update', 'delete'.
Backtrace for gem load error is:
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics/schema.rb:68:in `initialize'
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics/schema.rb:14:in `new'
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics/schema.rb:14:in `block in initialize'
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics/schema.rb:13:in `each'
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics/schema.rb:13:in `initialize'
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics/configuration.rb:36:in `new'
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics/configuration.rb:36:in `schema_filepath='
/Users/davidpell/.gem/ruby/2.3.1/gems/platform-api-1.0.1/config/client-config.rb:7:in `block in <top (required)>'
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics.rb:15:in `tap'
/Users/davidpell/.gem/ruby/2.3.1/gems/heroics-0.0.22/lib/heroics.rb:15:in `default_configuration'
/Users/davidpell/.gem/ruby/2.3.1/gems/platform-api-1.0.1/config/client-config.rb:4:in `<top (required)>'
/Users/davidpell/.gem/ruby/2.3.1/gems/platform-api-1.0.1/lib/platform-api.rb:4:in `require_relative'
/Users/davidpell/.gem/ruby/2.3.1/gems/platform-api-1.0.1/lib/platform-api.rb:4:in `<top (required)>'
/Users/davidpell/.gem/ruby/2.3.1/gems/bundler-1.14.6/lib/bundler/runtime.rb:91:in `require'
/Users/davidpell/.gem/ruby/2.3.1/gems/bundler-1.14.6/lib/bundler/runtime.rb:91:in `block (2 levels) in require'
/Users/davidpell/.gem/ruby/2.3.1/gems/bundler-1.14.6/lib/bundler/runtime.rb:86:in `each'
/Users/davidpell/.gem/ruby/2.3.1/gems/bundler-1.14.6/lib/bundler/runtime.rb:86:in `block in require'
/Users/davidpell/.gem/ruby/2.3.1/gems/bundler-1.14.6/lib/bundler/runtime.rb:75:in `each'
/Users/davidpell/.gem/ruby/2.3.1/gems/bundler-1.14.6/lib/bundler/runtime.rb:75:in `require'
/Users/davidpell/.gem/ruby/2.3.1/gems/bundler-1.14.6/lib/bundler.rb:107:in `require'

The error does not occur if I force gem 'heroics', '= 0.0.21' in Gemfile.

Remove heroics dependency

Shouldn't heroics just be a build/compile time dependency? It would be nice for heroics to be used once to generate code, and then only the generated code is needed. This would reduce runtime dependencies.

/cc @will

formation.update - option[:size] breaks call if dyno type is "free"

Version 0.0.7
(Since the repo does not have a Changelog, don't know if this is fixed and I can't update the gem for a while to test it)

App with new pricing model, "Free Dynos"

heroku.formation.update(@app_name, @proccess_name, size: '2x', quantity: 1)
Excon::Errors::UnprocessableEntity: Expected([200, 201, 202, 206, 304]) <=> Actual(422 Unprocessable Entity)

ConfigVar resource missing app_id_or_app_name

Maybe I'm missing something, but the ConfigVar resource does not have a way to specify the app_id_or_app_name:

# Get config-vars for app.
def info()
@client.config_var.info()
end
# Update config-vars for app. You can update existing config-vars by setting them again, and remove by setting it to `NULL`.
#
# @param body: the object to pass as the request payload
def update(body)
@client.config_var.update(body)
end

BadRequest - 400 BadRequest Missing Host Header on nearly all functions

I am using the client.connect_oauth(<oauth_token>) to generate my client but when trying to use the client to return client.config_var.info_for_app(app_name) (among other calls) Excon returns Excon::Error::BadRequest =>
'400 Bad Request: missing required Host header' (JSON::ParserError)

I am currently using version 1.0.1 and my oauth_token is generated via the CLI heroku authorizations:create --short

Can't delete oauth clients?

Not sure if this is a real problem or not, but I can't seem to delete oauth clients using platform-api. If I do something like @heroku.client.oauth_client.delete("redacted-uuid") debugging shows it's sending the param in the body rather than in the path. It looks like it's parsing the schema.json incorrectly, but perhaps I'm calling it wrong?

:path=>"/oauth/clients/{(%23%2Fdefinitions%2Foauth-client%2Fdefinitions%2Fidentity)}", :port=>443, :query=>nil, :scheme=>"https", ... :method=>:delete, :body=>"\"redacted-uuid\""

Calls to /apps use etag even though Endpoint does not support it

There is an issue in API where the etag for paginated items is not generated. Due to this the same the heroics client will always see a 304 from the /apps endpoint and always return the same list even if things have changed.

Here's an internal ticket about the issue:
https://github.com/heroku/api/issues/7691

This is a blocker to upgrade the Ruby buildpack and Java Buildpack test suites away from v2 of the API.

Wondering if we could add some kind of an option or method invocation to disable etag checking for certain calls, that would work around the issue in the short term.

Caching

We're using this gem to have a server status page of latest deploys. Since calls are cached (in the heroics gem), they often don't update.

Is there a way to disable this caching? I've tried passing in cache: false with no luck.

Excon warning: Invalid Excon connection keys: :thread_safe_sockets

Hi, I'm trying to use this gem in a Rake task to create or delete Heroku domains, and I'm running into this error. I wasn't able to find any issues on the Excon repo detailing how this could happen, so I'm starting by opening an issue here.

Thanks in advance for your help!

Some methods are not working after upgrading to 1.0

I have problems with couple of api methods after upgrading to 1.0.0. For now I've noticed this issue only for addon resource:

client = PlatformAPI.connect_oauth(ENV["HEROKU_TOKEN"])
client.addon.list_by_app("some-app-name")
NoMethodError: undefined method `addon' for #<Heroics::Client url="https://api.heroku.com">
	from /Users/ronin/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/heroics-0.0.21/lib/heroics/client.rb:30:in `method_missing'
	from /Users/ronin/.rbenv/versions/2.2.4/lib/ruby/gems/2.2.0/gems/platform-api-1.0.0/lib/platform-api/client.rb:839:in `list_by_app'

The same problem occurs for list and info. Is there any new way to invoke those methods or is it just a bug?

No error details given when response is an HTTP 422

client.domain.create('my_app', {hostname: "mydomain.com"})
Excon::Error::UnprocessableEntity: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(422 Unprocessable Entity)

with curl:

curl -v -n -X POST https://api.heroku.com/apps/$MY_APP/domains -d '{ "hostname": "mydomain.com" }' -H "Content-Type: application/json" -H "Authorization: Bearer $HEROKU_API_TOKEN"
...
< HTTP/1.1 422 status code 422
...
{
  "id":"invalid_params",
  "message":"mydomain.com is currently in use by another app."
}

Missing ability to refresh token

I don't see a way to refresh the OAuth token once it has expired. The #connect_oauth function only accepts the original token, which appears to expire after a few hours. The standard OAuth handshake, and credentials provided by omniauth-heroku include a refresh_token attribute which may be used to automatically obtain a new token one it has expired. It would be nice if this gem accepted the refresh_token as a param (or if it already does, document it somehow. I don't see anything in the gem docs here or in heroic.), and could automatically do the refreshed token exchange.

Add extra data to exceptions

When Excon get's an unexpected return value, can we add the ability to put the response in the error message. Currently it looks like this:

Excon::Error::UnprocessableEntity: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(422 Unprocessable Entity)

    /Users/schneems/.gem/ruby/2.4.1/gems/excon-0.55.0/lib/excon/middlewares/expects.rb:7:in `response_call'
    /Users/schneems/.gem/ruby/2.4.1/gems/excon-0.55.0/lib/excon/middlewares/response_parser.rb:9:in `response_call'
    /Users/schneems/.gem/ruby/2.4.1/gems/excon-0.55.0/lib/excon/connection.rb:388:in `response'
    /Users/schneems/.gem/ruby/2.4.1/gems/excon-0.55.0/lib/excon/connection.rb:252:in `request'
    /Users/schneems/.gem/ruby/2.4.1/gems/heroics-0.0.22/lib/heroics/link.rb:111:in `request_with_cache'
    /Users/schneems/.gem/ruby/2.4.1/gems/heroics-0.0.22/lib/heroics/link.rb:66:in `run'
    /Users/schneems/.gem/ruby/2.4.1/gems/heroics-0.0.22/lib/heroics/resource.rb:28:in `method_missing'
    /Users/schneems/.gem/ruby/2.4.1/gems/platform-api-2.0.0/lib/platform-api/client.rb:1231:in `update'
    /Users/schneems/Documents/projects/hatchet/lib/hatchet/app.rb:50:in `block in set_config'

It's impossible to know if it's due to throttling, or a bad json format on my side without drinking from the EXCON_DEBUG firehose.

In this case my issue was

  :body          => "{\"id\":\"invalid_params\",\"message\":\"Cannot destroy last attachment to billing app for resource postgresql-silhouetted-85198\"}"

But you have to know a lot about the internals of platform-api to get that.

Access to sni-endpoints API

The new sni-endpoints API appears to be available (albeit in beta) and is being used by the production dashboard at heroku.com.

Is there a general policy against including beta endpoints in the ruby gem? If not, I'll happily put together a PR to add this functionality.

Unable to create custom DNS + CNAME

I am trying to create a custom DNS + CNAMe via platform-api gem but still not able to set custom CNAME, e.g.

heroku = PlatformAPI.connect_oauth('API-key')
heroku.domain.create( 'brandnew-advertiser-fe-staging', {"hostname" => 'mediacom.brandnew.in', "kind" => "custom", "cname" => "brandnew-advertiser-fe-staging.herokuapp.com"})

# => {"app"=>{"id"=>"<APP_ID>", "name"=>"brandnew-advertiser-fe-staging"}, "cname"=>"mediacom.brandnew.in.herokudns.com", "created_at"=>"2017-01-13T10:02:40Z", "hostname"=>"mediacom.brandnew.in", "id"=>"<ID>", "kind"=>"custom", "status"=>"pending", "updated_at"=>"2017-01-13T10:02:40Z"}

you can see that cname is not same.

Support for Buildpacks?

I couldn't figure out how to use the set buildpack functionality of the Heroku API with this gem. Is it supported? If not, where should it be implemented? (I'd be glad to do it, I just don't really find my way around in the code yet.)

pg:wait, pg:info, or --fork using API

I am able to create a new Heroku Postgres addon using the Platform API. However, it is not clear how to provision a fork of an existing database and wait until the fork is complete.

I tried the following two options to provision the fork:

hk.addon.create('apartmentlist-production', { 'plan' => 'heroku-postgresql:standard-tengu', 'fork' => 'heroku-postgresql-black' } )
hk.addon.create('apartmentlist-production', { 'plan' => 'heroku-postgresql:standard-tengu', 'fork' => 'HEROKU_POSTGRESQL_BLACK_URL' } )

Both of the above provision an addon, but do not fork an existing DB.

Also, when I use the addon.info endpoint, I do not get any of the info that heroku pg:info command gives me. In particular I see no way to know if a newly provisioned DB has caught up and is ready for queries.

If Platform API is not the right tool for it, is there any other Heroku API that can help me accomplish forking a database and waiting until it is ready?

Only getting first 200 releases

I've documented the problem I'm seeing here: https://discussion.heroku.com/t/can-a-custom-buildpack-put-the-current-git-commit-sha-into-apps-env/932

Basically the below code only gives me the first 200 releases, and then calling last on that only gives me the 200th release every time.

Is there a call to just get the most recent release?

  # Added to allow us to cache static pages, with automatic cache invalidation using the git
  # head SHA
  def self.current_sha
    @current_sha ||=
      begin
        sha = nil
        tries = 0
        last_exception = nil
        while sha.nil? && tries < 10
          begin
            if ENV["HEROKU_TOKEN"].present?
              heroku = PlatformAPI.connect_oauth(ENV['HEROKU_TOKEN'])
              heroku_release_list = heroku.release.list(ENV['HEROKU_APP'])
              last_slug = heroku_release_list.last["slug"]
              slug_id = last_slug["id"]
              sha = heroku.slug.info(ENV['HEROKU_APP'], slug_id)["commit"]
              puts "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"
              puts "release list is #{heroku_release_list}"
              puts "last_slug = #{last_slug}"
              puts "slug_id is #{slug_id}"
              puts "slug info is #{heroku.slug.info(ENV['HEROKU_APP'], slug_id)}"
              puts "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ"
            else
              sha = `git rev-parse HEAD 2>/dev/null`.to_s.strip
            end
          rescue => e
            last_exception = e
            tries += 1
          end
        end
        if sha.nil?
          Utility.log_exception(last_exception)
        else
          Rails.logger.info { "Fetched current sha: '#{sha}'." }
        end
        sha
      end
  end

Missing get config for addons

I try get config from heroku addon.

This is relevant only for some addons for example deploy hooks and I can get url for check if is right.

heroku = PlatformAPI.connect_oauth(ENV['API_KEY'])
APP = 'myapp-uniq-name'
ADDON = 'DEPLOYHOOKS_HTTP'
ADDON_NAME = 'building-softly-5771'

# I try all this things but URL for isn't there
heroku.addon_service.info('deployhooks')
heroku.addon_attachment.list_by_app(APP)
heroku.addon_attachment.info_by_app(APP, ADDON)
heroku.addon.info(ADDON_NAME)

Update: I found some of them in config_vars but doesn't declare in addon info. It's possible get them directly? For example at deploy hooks (http, email) missing DEPLOYHOOKS_HTTP_URL

{
  "config_vars": [

  ],
  "created_at": "2015-04-21T04:39:17Z",
  "id": "<uuid>",
  "name": "<name-id>",
  "addon_service": {
    "id": "<uuid>",
    "name": "deployhooks"
  },
  "plan": {
    "id": "<uuid>",
    "name": "deployhooks:http"
  },
  "app": {
    "id": "<uuid>",
    "name": "myapp"
  },
  "provider_id": "15892",
  "updated_at": "2015-04-21T04:39:17Z",
  "web_url": "https://addons-sso.heroku.com/apps/apiary/addons/<uuid>"
}

Allow sending commands to add-ons

I'm a bit baffled by the following set of decisions.

  1. Deprecate the heroku gem.
  2. Don't install the "Heroku Toolbelt" by default on Heroku instances.

This forces users to use something like the Heroku buildpack: Heroku Toolbelt to run heroku commands on their staging server.

The platform-api provides a partial solution by creating something that can be accessed by a rake task,, but it would be great if it allowed interactions with addons, such as pgbackups or pgextras.

Thanks!
-Lee

closed

Add-on List
List existing add-ons.
Acceptable order values for the Range header are id or name.
GET /apps/{app_id_or_name}/addons
Curl Example
$ curl -n -X GET https://api.heroku.com/apps/$APP_ID_OR_NAME/addons \
-H "Accept: application/vnd.heroku+json; version=3"
Response Example
HTTP/1.1 200 OK
Accept-Ranges: id, name
Content-Range: id 01234567-89ab-cdef-0123-456789abcdef..01234567-89ab-cdef-0123-456789abcdef; max=200
ETag: "0123456789abcdef0123456789abcdef"
Last-Modified: Sun, 01 Jan 2012 12:00:00 GMT
RateLimit-Remaining: 2400
[
  {
    "addon_service": {
      "id": "01234567-89ab-cdef-0123-456789abcdef",
      "name": "heroku-postgresql"
    },
    "app": {
      "id": "01234567-89ab-cdef-0123-456789abcdef",
      "name": "example"
    },
    "config_vars": [
      "FOO",
      "BAZ"
    ],
    "created_at": "2012-01-01T12:00:00Z",
    "id": "01234567-89ab-cdef-0123-456789abcdef",
    "name": "heroku-postgresql-teal",
    "plan": {
      "id": "01234567-89ab-cdef-0123-456789abcdef",
      "name": "heroku-postgresql:dev"
    },
    "provider_id": "[email protected]",
    "updated_at": "2012-01-01T12:00:00Z"
  }
]

Support for webhooks?

This looks to be pretty out of date, are there plans to add the endpoints like webhooks to this?

Add hooks so Let's Encrypt can be directly supported

Heroku's automated HTTPS certificate management was recently announced, based on the widely-used Let's Encrypt service. However, Heroku's mechanism cannot be used with CDNs (like Fastly or CloudFlare), which makes the new service useless for a lot of people. Gem letsencrypt-rails-heroku enables people to use Let's Encrypt even with a CDN.

However, this gem requires a modified version of platform-api, here: https://github.com/jalada/platform-api

Can heroku/platform-api be modified so that it includes the hooks needed to support the gem letsencrypt-rails-heroku ?

Thanks!

Disabled Heroku SSLv3 has broken this gem

This past Thursday (10/16/14), Heroku disabled SSLv3 across all SSL endpoints: https://status.heroku.com/incidents/678

As a result, all API requests using PlatformAPI are currently failing:

Excon::Errors::SocketError: SSL_connect returned=1 errno=0 state=SSLv3 read server hello A: sslv3 alert handshake failure (OpenSSL::SSL::SSLError)
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/excon-0.16.4/lib/excon/ssl_socket.rb:60:in `connect'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/excon-0.16.4/lib/excon/ssl_socket.rb:60:in `initialize'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/excon-0.16.4/lib/excon/connection.rb:362:in `new'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/excon-0.16.4/lib/excon/connection.rb:362:in `socket'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/excon-0.16.4/lib/excon/connection.rb:193:in `request_kernel'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/excon-0.16.4/lib/excon/connection.rb:96:in `block in request'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/excon-0.16.4/lib/excon/standard_instrumentor.rb:11:in `instrument'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/excon-0.16.4/lib/excon/connection.rb:95:in `request'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/heroics-0.0.12/lib/heroics/link.rb:60:in `run'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/heroics-0.0.12/lib/heroics/resource.rb:27:in `method_missing'
    from /usr/local/rvm/gems/ruby-2.0.0-p353/gems/platform-api-0.2.0/lib/platform-api/client.rb:568:in `info'

In order to fix this, Excon needs to make requests using TLSv1.0 or higher.

Stop one off Dyno with custom Type

Potential Bug
Start a one-off dyno with this command

heroku.dyno.create(heroku_app, {command: "while :; do echo 'hit ctrl-c'; sleep 1; done", type: "test"})

Heroku logs this:

app[api]: Starting process with command 'while :; do echo 'hit ctrl-c'; sleep 1; done' by user

But this Dyno is not killed with the command

heroku.dyno.restart(heroku_app, "test.1234") # assuming the Dyno name is test.1234 Returned is an empty hash {}

Stopping with heroku ps:stop test.1234 works

This does not occur if you do not specify the "type" during the create call. For example, you can kill a one-off Dyno that is named something like run.1234

Installing a buildpack

I can't seem to find the correct name to use for installing a buildpack via the gem. Let's say I initialized a connection and assigned it to platform_api. To update the installation of buildpacks for an app, I would assume it would be something like:

platform_api.buildpack_installation.update("my_app", {"buildpack" => "nameofbuildpack"})

However I just get 422's back saying that buildpack is an unknown param. Looking at the platform api documentation here: https://devcenter.heroku.com/articles/platform-api-reference#buildpack-installations
It looks like I should be sending an array but it doesn't look like any of the other actions send arrays in this gem. I can't seem to find any working combination. Any help would be appreciated.

Changelog / release guide?

It would be really helpful to see a changelog or history.md or similar type file. For example I've got an app on 0.3.0 and I can't tell if anything if there are any backwards incompatible changes to bring it to the latest version.

Consider renaming the gem

This gem has a very generic name (platform-api). The require 'platform-api' bit is weird, and it's not clear what platform you're talking about. That's especially true when using it from ruby code as PlatformAPI.

At the very least it would be a good idea to nest that to Heroku::PlatformAPI and then you could require heroku-platform-api or something like that.

Pagination does not work with caching

I'm using platform-api 0.2.0, heroics 0.0.12.

The client is caching the first page of responses only. So the first API call returns a full set of results, whereas subsequent calls return only partial results. Turning off caching fixes the issue.

2.1.1 :001 > require 'platform-api'
 => true
2.1.1 :002 > heroku = PlatformAPI.connect_oauth(token)
 => #<PlatformAPI::Client:0x00000103984780 @client=#<Heroics::Client url="https://api.heroku.com">>
2.1.1 :003 > heroku.release.list(app_name).count
 => 841
2.1.1 :004 > heroku.release.list(app_name).count
 => 200

Error on SNI Endpoint Update

Hi there!

I'm trying to update the SSL certificate programmatically with the SNI Endpoint update function, specifying the APP_NAME, SNI_ENDPOINT_ID, the certificate_chain and the private_key and I'm getting the following error:

Excon::Error::UnprocessableEntity: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(422 Unprocessable Entity)
from /usr/local/bundle/gems/excon-0.62.0/lib/excon/middlewares/expects.rb:7:in `response_call'
from /usr/local/bundle/gems/excon-0.62.0/lib/excon/middlewares/response_parser.rb:9:in `response_call'
from /usr/local/bundle/gems/excon-0.62.0/lib/excon/connection.rb:414:in `response'
from /usr/local/bundle/gems/excon-0.62.0/lib/excon/connection.rb:263:in `request'
from /usr/local/bundle/gems/heroics-0.0.25/lib/heroics/link.rb:111:in `request_with_cache'
from /usr/local/bundle/gems/heroics-0.0.25/lib/heroics/link.rb:66:in `run'
from /usr/local/bundle/gems/heroics-0.0.25/lib/heroics/resource.rb:28:in `method_missing'
from /usr/local/bundle/gems/platform-api-2.2.0/lib/platform-api/client.rb:2835:in `update'
from (irb):6
from /usr/local/bundle/gems/railties-4.2.7.1/lib/rails/commands/console.rb:110:in `start'
from /usr/local/bundle/gems/railties-4.2.7.1/lib/rails/commands/console.rb:9:in `start'
from /usr/local/bundle/gems/railties-4.2.7.1/lib/rails/commands/commands_tasks.rb:68:in `console'
from /usr/local/bundle/gems/railties-4.2.7.1/lib/rails/commands/commands_tasks.rb:39:in `run_command!'
from /usr/local/bundle/gems/railties-4.2.7.1/lib/rails/commands.rb:17:in `<top (required)>'
from bin/rails:8:in `require'
from bin/rails:8:in `<main>'`

Any idea why this is happening? I can list the SNI endpoints, show the info of the SNI Endpoint but can't update it.

Thanks in advance! Greetings!

heroku.account.info wrong number of arguments

The docs aren't clear how to get the info for the current account. #info (incorrectly, IMHO) requires at least 1 argument, while the Platform API indicates none is required for /account.

Digging into the generated source, the argument name account_email_or_account_id_or_account_self implies that an "account_self" is a permissible option, but it is not at all clear how to get one.

My wild-ass guesses:

[1] pry(main)> heroku = PlatformAPI.connect_oauth("...")
=> #<PlatformAPI::Client:0x007fd21e3fd520 @client=#<Heroics::Client url="https://api.heroku.com">>
[2] pry(main)> heroku.account.info
ArgumentError: wrong number of arguments (0 for 1)
from /Users/rando/.gem/ruby/2.2.3/gems/platform-api-0.5.0/lib/platform-api/client.rb:531:in `info'
[3] pry(main)> heroku.account.info nil
Excon::Errors::NotFound: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(404 Not Found)
from /Users/rando/.gem/ruby/2.2.3/gems/excon-0.45.4/lib/excon/middlewares/expects.rb:6:in `response_call'
[4] pry(main)> heroku.account.info "self"
Excon::Errors::NotFound: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(404 Not Found)
from /Users/rando/.gem/ruby/2.2.3/gems/excon-0.45.4/lib/excon/middlewares/expects.rb:6:in `response_call'
[5] pry(main)> heroku.account.info(heroku.account)
Excon::Errors::NotFound: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(404 Not Found)
from /Users/rando/.gem/ruby/2.2.3/gems/excon-0.45.4/lib/excon/middlewares/expects.rb:6:in `response_call'

Delay on custom domain list status

platform = PlatformAPI.connect_oauth(key)
hostnames = heroku.domain.list(app_name).map { |x| x['hostname'] }
platform.domain.create(APP_NAME, 'hostname' => "www.sampleDomain.com") unless 

# create domain
hostnames.include? "www.someDomain.com"
=> {"acm_status"=>nil, "app"=>{...}, "cname"=>"www.sampleDomain.com.herokudns.com", "created_at"=>..., "hostname"=>"www.sampleDomain.com", "kind"=>"custom", "status"=>"succeeded", "updated_at"=>....}

# check in the list
platform.domain.list(APP_NAME).map { |x| x['hostname'] }.include? "www.sampleDomain.com"
=> false # any reason?

Sometimes, it took about 15 mins+ for the custom domain to be found in list.
Is there a way to tell whether the custom domain will be added to the list?
Can I rely on domain.list api? If not, what is the alternative?

Errno::EACCES: Permission denied @ dir_s_mkdir - /home/webapp

I have an application that's using Platform API deployed to AWS EC2. Problem is that I see this exception Errno::EACCES: Permission denied @ dir_s_mkdir - /home/webapp when I try to instantiate Platform API client. The relevant exception happens on this line of code.

I actually think that there are 2 problems here:

  1. Platform API choice of a file cache in the home directory doesn't work in all scenarios.
  2. Although Platform API client allows overriding the cache with an option (PlatformAPI.connect('my-api-key', cache: Moneta.new(:Memory))) the client is written in such a way that it tries to create the file store in the home directory, although it's not going to be used - https://github.com/heroku/platform-api/blob/v0.5.0/lib/platform-api/client.rb#L64. This is actually a problem in Heroics.

I'm not sure what the optimal solution is but I would like to ask you to consider changing one or both of those things. Let me know if you need any further information on this. Thanks!

app.create doesn't work for me

In your README you have heroku.app.create after initializing the client with a token. Is this supposed to work? I installed the lastest from Rubygems...

No apparent way to access /account endpoint

The client.account.info method actually goes to the GET /users/:email_or_id endpoint, which is making it stupidly hard to look up current_user info for an oauth_token, where GET /account is all you need.

I'm guessing the method is getting stomped on because of how classes are auto generated.

heroku.app.create => ArgumentError: wrong number of arguments (0 for 1)

user@ubuntu:~$ irb
irb(main):001:0> require 'platform-api'
=> true
irb(main):002:0> heroku = PlatformAPI.connect_oauth('e7dd6ad7-3c6a-411e-a2be-c9fe52ac7ed2')
=> #<PlatformAPI::Client:0x007f0c64a95048 @client=#<Heroics::Client url="https://api.heroku.com">>
irb(main):003:0> heroku.app.create
ArgumentError: wrong number of arguments (0 for 1)
from /home/user/.rbenv/versions/2.3.0-dev/lib/ruby/gems/2.3.0/gems/platform-api-0.3.0/lib/platform-api/client.rb:645:in create' from (irb):3 from /home/user/.rbenv/versions/2.3.0-dev/bin/irb:11:in

'
irb(main):004:0>

Restart all dynos not working

When I pass a restart_all command to the Dyno class, the app doesn't get restarted, but it does return an empty hash.

class HerokuWrapper

    attr_reader :api_key, :app_name, :heroku_api, :key_extractor

    def initialize(app_name)
      @app_name      = app_name
      @key_extractor = LocalApiKeyExtractor
      @api_key          = key_extractor.get_credentials
      @heroku_api    = PlatformAPI.connect_oauth(api_key)
    end

    def app_restart
      client(:dyno, :restart_all, app_name)
    end

    private

    def client(delegatee, method, *args)
      heroku_api.public_send(delegatee).public_send(method, *args)
    end

  end
end

Essentially I'm running @client.dyno.restart_all(app_id_or_app_name) to no avail.

When I try to restart all dynos, the app doesn't get restarted, but it does return an empty hash {}.

Readme samples use incorrectly 1X and 2X as size arguments, but that doesn't work

Gives error:

[8] pry(main)> heroku.formation.update s.name, 'web', { quantity: 1, size: "1X" }
Excon::Error::UnprocessableEntity: Expected([200, 201, 202, 204, 206, 304]) <=> Actual(422 Unprocessable Entity)
from /Users/timo/.rvm/gems/ruby-2.3.0@api/gems/excon-0.60.0/lib/excon/middlewares/expects.rb:7:in `response_call'

As one might expect, this works:

heroku.formation.update s.name, 'web', { quantity: 1, size: "Standard-1X" }

log_session.create body should be optional

Looking at http://heroku.github.io/platform-api/PlatformAPI/LogDrain.html#create-instance_method which is powered by https://devcenter.heroku.com/articles/platform-api-reference#log-session-create , all the parameters are optional, so I don't think log_session.create should require a body parameter.

This fails:

heroku.log_session.create(name, :lines => 100)
# vendor/gems/ruby/2.1.0/gems/platform-api-0.7.0/lib/platform-api/client.rb:1397:in `create': wrong number of arguments (1 for 2) (ArgumentError)

But this works:

    log_session = heroku_platform_api.log_session.create(name, {})

I've looked at the code of this gem enough to know it's generated by heroics, but I'm not sure this change is possible.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.