Re: Programmatic access to heroku with the Heroku Client gem
Good points. I'd say similar things apply for api keys, though not entirely. 1. Every developer should have their own Heroku account as well. 2. The reason the key upload is require is (so far as I'm aware) just for the purposes of git, and we have discussed perhaps allowing this to work with api key stuff. 3. True, not sure how to get around this part. Although lately Github has also been pushing for people to use https transfer and store the password in keychain or something. heroku login is required and automatically happens if you try to do anything without having already done it. Also, after entering your user/pass it already caches the api key locally. So if you look at your ~/.netrc file you should be able to see you api key instead of your password (though it is labeled as password due to limitations in the netrc format). I certainly understand your points as well, but I think that at the moment things internally are leaning toward api key based consistent auth. I'll keep your feedback in mind though. Thanks! wes On May 10, 6:28 am, Daniel Doubrovkine wrote: > I would definitely prefer the SSH key because: > > 1. Every developer already has one. > 2. It's the preferred authentication with Heroku for the command line > client, you have to upload your key when you set it up the first time. > 3. It's the preferred authentication with Github and many other services > developers use daily. > > All that said, what matters i the initial setup. Right now it means > doing *heroku > keys:add*. If I have to do *heroku login > --save-my-api-key-to-local-machine-for-future-authentication-via-heroku-api * > that > might work too. > > cheers > dB. > > > > > > > > > > On Tue, May 8, 2012 at 11:07 AM, geemus wrote: > > I'm happy to continue discussing pretty much indefinitely, I just didn't > > want you to think I was blowing you off or not paying attention or > > something. > > > I can certainly see the value of a single secret. I think we may actually > > be moving more toward that model, but I think the defacto credential we > > were settling toward was actually the API key. If there were only one > > credential, but it was the API key, would that be satisfactory? Would you > > prefer the SSH key as the single secret? > > > On Monday, May 7, 2012 2:05:43 PM UTC-5, dB. wrote: > > >> No, please, lets get going :) I really appreciate you replying. Something > >> good will come out of this! > > >> I want users to have one single secret - their SSH key should let me > >> obtain their API key, I don't want to store that anywhere. No? > > >> On Mon, May 7, 2012 at 11:46 AM, geemus wrote: > > >>> I'm not sure what you mean exactly. You say that the API key is a > >>> single key for all clients. Do all the developers use the same heroku > >>> account? If they all have different accounts and API keys I think that > >>> there are capabilities for controlling access in a bit more fine grained > >>> way. I would also expect that the SSH key is the key to git usage, but > >>> that the API key is key to everything else. As such I would expect that > >>> each user would have their own and that they would need to have these > >>> unique credentials locally to be able to utilize the API in the first > >>> place. Is that not how you have structured things? > > >>> Sorry to be going, perhaps backwards there, but I didn't quite follow a > >>> couple of your statements, so a little clarification would be great. > >>> Thanks! > >>> wes > > >>> On Friday, May 4, 2012 6:51:39 AM UTC-5, dB. wrote: > > Lets back-up for a second :) > > The point is that we don't want to hard-code any credentials on the > client. You have an SSH key and that's the key to the kingdom. And it's > your SSH key, not someone else's. And we want to be able to fetch > variables > from your default heroku application identified by a git remote. > > Heroku-api doesn't work like this, it wants an API key. It's a single > key for all clients, and we don't want that. It would mean committing it > to > source control, not being able to kick out developers that leave the > team, > etc. So there would be two action items here: modify the code to support > SSH auth, add code that figures out the default app from the git remote > to > this gem. > > Heroku client works like this, it uses your SSH credentials to > authenticate. It also has the code to figure out the default heroku > application from git remotes, but that code is buried in the gem and is > not > accessible unless you execute a command. This would need some refactoring > to pull out the default application name. > > @geemus, what would you do? > > On Thu, May 3, 2012 at 6:00 PM, geemus wrote: > > > That does make sense. The way I usually do something like that is to > > set the rake task to just look for S3_BUCKET on my local machine as well > >
Re: Programmatic access to heroku with the Heroku Client gem
I would definitely prefer the SSH key because: 1. Every developer already has one. 2. It's the preferred authentication with Heroku for the command line client, you have to upload your key when you set it up the first time. 3. It's the preferred authentication with Github and many other services developers use daily. All that said, what matters i the initial setup. Right now it means doing *heroku keys:add*. If I have to do *heroku login --save-my-api-key-to-local-machine-for-future-authentication-via-heroku-api* that might work too. cheers dB. On Tue, May 8, 2012 at 11:07 AM, geemus wrote: > I'm happy to continue discussing pretty much indefinitely, I just didn't > want you to think I was blowing you off or not paying attention or > something. > > I can certainly see the value of a single secret. I think we may actually > be moving more toward that model, but I think the defacto credential we > were settling toward was actually the API key. If there were only one > credential, but it was the API key, would that be satisfactory? Would you > prefer the SSH key as the single secret? > > > On Monday, May 7, 2012 2:05:43 PM UTC-5, dB. wrote: >> >> No, please, lets get going :) I really appreciate you replying. Something >> good will come out of this! >> >> I want users to have one single secret - their SSH key should let me >> obtain their API key, I don't want to store that anywhere. No? >> >> On Mon, May 7, 2012 at 11:46 AM, geemus wrote: >> >>> I'm not sure what you mean exactly. You say that the API key is a >>> single key for all clients. Do all the developers use the same heroku >>> account? If they all have different accounts and API keys I think that >>> there are capabilities for controlling access in a bit more fine grained >>> way. I would also expect that the SSH key is the key to git usage, but >>> that the API key is key to everything else. As such I would expect that >>> each user would have their own and that they would need to have these >>> unique credentials locally to be able to utilize the API in the first >>> place. Is that not how you have structured things? >>> >>> Sorry to be going, perhaps backwards there, but I didn't quite follow a >>> couple of your statements, so a little clarification would be great. >>> Thanks! >>> wes >>> >>> >>> On Friday, May 4, 2012 6:51:39 AM UTC-5, dB. wrote: Lets back-up for a second :) The point is that we don't want to hard-code any credentials on the client. You have an SSH key and that's the key to the kingdom. And it's your SSH key, not someone else's. And we want to be able to fetch variables from your default heroku application identified by a git remote. Heroku-api doesn't work like this, it wants an API key. It's a single key for all clients, and we don't want that. It would mean committing it to source control, not being able to kick out developers that leave the team, etc. So there would be two action items here: modify the code to support SSH auth, add code that figures out the default app from the git remote to this gem. Heroku client works like this, it uses your SSH credentials to authenticate. It also has the code to figure out the default heroku application from git remotes, but that code is buried in the gem and is not accessible unless you execute a command. This would need some refactoring to pull out the default application name. @geemus, what would you do? On Thu, May 3, 2012 at 6:00 PM, geemus wrote: > That does make sense. The way I usually do something like that is to > set the rake task to just look for S3_BUCKET on my local machine as well > and then each developer could just export the appropriate environment > variable locally to make things work. You might want to namespace it a > bit > though, especially if you have multiple apps, to something like > MYAPP_S3_BUCKET, just to avoid conflicts. > > That doesn't really answer the initial question though. I'm not > exactly sure what the best way to find the default app in a case like that > would be. Perhaps there should be a command that would output it, similar > to how you can use `heroku auth:user` or `heroku auth:token` to make the > client parse credentials and spit them out for you. Maybe something like > `heroku apps:current` or something. Thoughts? > > wes > > On Thursday, May 3, 2012 10:48:47 AM UTC-5, dB. wrote: >> >> Take the example of a rake task that pushes a deployment to Heroku >> along with some S3 assets. Every developer has their own heroku >> application, and they configure it by creating a Heroku remote origin. >> >> To push to heroku a developer does do *git push heroku master*, then >> they need to push some assets to their own S3 bucket (eg. >> developer-bucket). The name of the bucket is c
Re: Programmatic access to heroku with the Heroku Client gem
I'm happy to continue discussing pretty much indefinitely, I just didn't want you to think I was blowing you off or not paying attention or something. I can certainly see the value of a single secret. I think we may actually be moving more toward that model, but I think the defacto credential we were settling toward was actually the API key. If there were only one credential, but it was the API key, would that be satisfactory? Would you prefer the SSH key as the single secret? On Monday, May 7, 2012 2:05:43 PM UTC-5, dB. wrote: > > No, please, lets get going :) I really appreciate you replying. Something > good will come out of this! > > I want users to have one single secret - their SSH key should let me > obtain their API key, I don't want to store that anywhere. No? > > On Mon, May 7, 2012 at 11:46 AM, geemus wrote: > >> I'm not sure what you mean exactly. You say that the API key is a single >> key for all clients. Do all the developers use the same heroku account? >> If they all have different accounts and API keys I think that there are >> capabilities for controlling access in a bit more fine grained way. I >> would also expect that the SSH key is the key to git usage, but that the >> API key is key to everything else. As such I would expect that each user >> would have their own and that they would need to have these unique >> credentials locally to be able to utilize the API in the first place. Is >> that not how you have structured things? >> >> Sorry to be going, perhaps backwards there, but I didn't quite follow a >> couple of your statements, so a little clarification would be great. >> Thanks! >> wes >> >> >> On Friday, May 4, 2012 6:51:39 AM UTC-5, dB. wrote: >>> >>> Lets back-up for a second :) >>> >>> The point is that we don't want to hard-code any credentials on the >>> client. You have an SSH key and that's the key to the kingdom. And it's >>> your SSH key, not someone else's. And we want to be able to fetch variables >>> from your default heroku application identified by a git remote. >>> >>> Heroku-api doesn't work like this, it wants an API key. It's a single >>> key for all clients, and we don't want that. It would mean committing it to >>> source control, not being able to kick out developers that leave the team, >>> etc. So there would be two action items here: modify the code to support >>> SSH auth, add code that figures out the default app from the git remote to >>> this gem. >>> >>> Heroku client works like this, it uses your SSH credentials to >>> authenticate. It also has the code to figure out the default heroku >>> application from git remotes, but that code is buried in the gem and is not >>> accessible unless you execute a command. This would need some refactoring >>> to pull out the default application name. >>> >>> @geemus, what would you do? >>> >>> On Thu, May 3, 2012 at 6:00 PM, geemus wrote: >>> That does make sense. The way I usually do something like that is to set the rake task to just look for S3_BUCKET on my local machine as well and then each developer could just export the appropriate environment variable locally to make things work. You might want to namespace it a bit though, especially if you have multiple apps, to something like MYAPP_S3_BUCKET, just to avoid conflicts. That doesn't really answer the initial question though. I'm not exactly sure what the best way to find the default app in a case like that would be. Perhaps there should be a command that would output it, similar to how you can use `heroku auth:user` or `heroku auth:token` to make the client parse credentials and spit them out for you. Maybe something like `heroku apps:current` or something. Thoughts? wes On Thursday, May 3, 2012 10:48:47 AM UTC-5, dB. wrote: > > Take the example of a rake task that pushes a deployment to Heroku > along with some S3 assets. Every developer has their own heroku > application, and they configure it by creating a Heroku remote origin. > > To push to heroku a developer does do *git push heroku master*, then > they need to push some assets to their own S3 bucket (eg. > developer-bucket). The name of the bucket is configured as a S3_BUCKET > variable on their heroku application. Right now we execute 'heroku config > --long', parse that to figure out what the S3_BUCKET is, which is not > ideal. Nowhere the Rake task knows the name of the remote Heroku > application. > > Of course we could force every developer to hardcode the name of their > application somewhere on the client, but we might as well keep our heroku > config output parsing instead. > > Makes sense? > > On Wed, May 2, 2012 at 12:10 PM, geemus wrote: > >> I'd actually recommend checking out the heroku-api gem for >> programatic access. You can co
Re: Programmatic access to heroku with the Heroku Client gem
No, please, lets get going :) I really appreciate you replying. Something
good will come out of this!
I want users to have one single secret - their SSH key should let me obtain
their API key, I don't want to store that anywhere. No?
On Mon, May 7, 2012 at 11:46 AM, geemus wrote:
> I'm not sure what you mean exactly. You say that the API key is a single
> key for all clients. Do all the developers use the same heroku account?
> If they all have different accounts and API keys I think that there are
> capabilities for controlling access in a bit more fine grained way. I
> would also expect that the SSH key is the key to git usage, but that the
> API key is key to everything else. As such I would expect that each user
> would have their own and that they would need to have these unique
> credentials locally to be able to utilize the API in the first place. Is
> that not how you have structured things?
>
> Sorry to be going, perhaps backwards there, but I didn't quite follow a
> couple of your statements, so a little clarification would be great.
> Thanks!
> wes
>
>
> On Friday, May 4, 2012 6:51:39 AM UTC-5, dB. wrote:
>>
>> Lets back-up for a second :)
>>
>> The point is that we don't want to hard-code any credentials on the
>> client. You have an SSH key and that's the key to the kingdom. And it's
>> your SSH key, not someone else's. And we want to be able to fetch variables
>> from your default heroku application identified by a git remote.
>>
>> Heroku-api doesn't work like this, it wants an API key. It's a single key
>> for all clients, and we don't want that. It would mean committing it to
>> source control, not being able to kick out developers that leave the team,
>> etc. So there would be two action items here: modify the code to support
>> SSH auth, add code that figures out the default app from the git remote to
>> this gem.
>>
>> Heroku client works like this, it uses your SSH credentials to
>> authenticate. It also has the code to figure out the default heroku
>> application from git remotes, but that code is buried in the gem and is not
>> accessible unless you execute a command. This would need some refactoring
>> to pull out the default application name.
>>
>> @geemus, what would you do?
>>
>> On Thu, May 3, 2012 at 6:00 PM, geemus wrote:
>>
>>> That does make sense. The way I usually do something like that is to
>>> set the rake task to just look for S3_BUCKET on my local machine as well
>>> and then each developer could just export the appropriate environment
>>> variable locally to make things work. You might want to namespace it a bit
>>> though, especially if you have multiple apps, to something like
>>> MYAPP_S3_BUCKET, just to avoid conflicts.
>>>
>>> That doesn't really answer the initial question though. I'm not exactly
>>> sure what the best way to find the default app in a case like that would
>>> be. Perhaps there should be a command that would output it, similar to how
>>> you can use `heroku auth:user` or `heroku auth:token` to make the client
>>> parse credentials and spit them out for you. Maybe something like `heroku
>>> apps:current` or something. Thoughts?
>>>
>>> wes
>>>
>>> On Thursday, May 3, 2012 10:48:47 AM UTC-5, dB. wrote:
Take the example of a rake task that pushes a deployment to Heroku
along with some S3 assets. Every developer has their own heroku
application, and they configure it by creating a Heroku remote origin.
To push to heroku a developer does do *git push heroku master*, then
they need to push some assets to their own S3 bucket (eg.
developer-bucket). The name of the bucket is configured as a S3_BUCKET
variable on their heroku application. Right now we execute 'heroku config
--long', parse that to figure out what the S3_BUCKET is, which is not
ideal. Nowhere the Rake task knows the name of the remote Heroku
application.
Of course we could force every developer to hardcode the name of their
application somewhere on the client, but we might as well keep our heroku
config output parsing instead.
Makes sense?
On Wed, May 2, 2012 at 12:10 PM, geemus wrote:
> I'd actually recommend checking out the heroku-api gem for programatic
> access. You can cover your example then this way:
>
> require "heroku-api"
> api = Heroku::API.new(:api_key => XXX)
> api.get_convig_vars("my-app").body
>
> That said, I'm not sure what the best answer is on the default app
> front. Could you describe how you intend to use this information? I
> think
> that might help me narrow down a recommendation and/or fix it up to make
> it
> easier to do what you need.
>
> Thanks!
> wes
>
>
> On Tuesday, May 1, 2012 5:48:22 PM UTC-5, dB. wrote:
>>
>> I'm trying to replace some code in a Rake task that executes 'heroku
>> config --long' and parses the output.
>>
>> I can
Re: Programmatic access to heroku with the Heroku Client gem
I'm not sure what you mean exactly. You say that the API key is a single
key for all clients. Do all the developers use the same heroku account?
If they all have different accounts and API keys I think that there are
capabilities for controlling access in a bit more fine grained way. I
would also expect that the SSH key is the key to git usage, but that the
API key is key to everything else. As such I would expect that each user
would have their own and that they would need to have these unique
credentials locally to be able to utilize the API in the first place. Is
that not how you have structured things?
Sorry to be going, perhaps backwards there, but I didn't quite follow a
couple of your statements, so a little clarification would be great.
Thanks!
wes
On Friday, May 4, 2012 6:51:39 AM UTC-5, dB. wrote:
>
> Lets back-up for a second :)
>
> The point is that we don't want to hard-code any credentials on the
> client. You have an SSH key and that's the key to the kingdom. And it's
> your SSH key, not someone else's. And we want to be able to fetch variables
> from your default heroku application identified by a git remote.
>
> Heroku-api doesn't work like this, it wants an API key. It's a single key
> for all clients, and we don't want that. It would mean committing it to
> source control, not being able to kick out developers that leave the team,
> etc. So there would be two action items here: modify the code to support
> SSH auth, add code that figures out the default app from the git remote to
> this gem.
>
> Heroku client works like this, it uses your SSH credentials to
> authenticate. It also has the code to figure out the default heroku
> application from git remotes, but that code is buried in the gem and is not
> accessible unless you execute a command. This would need some refactoring
> to pull out the default application name.
>
> @geemus, what would you do?
>
> On Thu, May 3, 2012 at 6:00 PM, geemus wrote:
>
>> That does make sense. The way I usually do something like that is to set
>> the rake task to just look for S3_BUCKET on my local machine as well and
>> then each developer could just export the appropriate environment variable
>> locally to make things work. You might want to namespace it a bit though,
>> especially if you have multiple apps, to something like MYAPP_S3_BUCKET,
>> just to avoid conflicts.
>>
>> That doesn't really answer the initial question though. I'm not exactly
>> sure what the best way to find the default app in a case like that would
>> be. Perhaps there should be a command that would output it, similar to how
>> you can use `heroku auth:user` or `heroku auth:token` to make the client
>> parse credentials and spit them out for you. Maybe something like `heroku
>> apps:current` or something. Thoughts?
>>
>> wes
>>
>> On Thursday, May 3, 2012 10:48:47 AM UTC-5, dB. wrote:
>>>
>>> Take the example of a rake task that pushes a deployment to Heroku along
>>> with some S3 assets. Every developer has their own heroku application, and
>>> they configure it by creating a Heroku remote origin.
>>>
>>> To push to heroku a developer does do *git push heroku master*, then
>>> they need to push some assets to their own S3 bucket (eg.
>>> developer-bucket). The name of the bucket is configured as a S3_BUCKET
>>> variable on their heroku application. Right now we execute 'heroku config
>>> --long', parse that to figure out what the S3_BUCKET is, which is not
>>> ideal. Nowhere the Rake task knows the name of the remote Heroku
>>> application.
>>>
>>> Of course we could force every developer to hardcode the name of their
>>> application somewhere on the client, but we might as well keep our heroku
>>> config output parsing instead.
>>>
>>> Makes sense?
>>>
>>> On Wed, May 2, 2012 at 12:10 PM, geemus wrote:
>>>
I'd actually recommend checking out the heroku-api gem for programatic
access. You can cover your example then this way:
require "heroku-api"
api = Heroku::API.new(:api_key => XXX)
api.get_convig_vars("my-app").**body
That said, I'm not sure what the best answer is on the default app
front. Could you describe how you intend to use this information? I
think
that might help me narrow down a recommendation and/or fix it up to make
it
easier to do what you need.
Thanks!
wes
On Tuesday, May 1, 2012 5:48:22 PM UTC-5, dB. wrote:
>
> I'm trying to replace some code in a Rake task that executes 'heroku
> config --long' and parses the output.
>
> I can do this:
>
> c = Heroku::Client.new(* Heroku::Auth.read_credentials)
> c.config_vars("my-app")
>
> Awesome, this returns the configuration variables for my-app as a
> Hash.
>
> The next problem is how to figure out the default app name - in
> development environments we often want to have our tasks run against our
>
Re: Programmatic access to heroku with the Heroku Client gem
Lets back-up for a second :)
The point is that we don't want to hard-code any credentials on the client.
You have an SSH key and that's the key to the kingdom. And it's your SSH
key, not someone else's. And we want to be able to fetch variables from
your default heroku application identified by a git remote.
Heroku-api doesn't work like this, it wants an API key. It's a single key
for all clients, and we don't want that. It would mean committing it to
source control, not being able to kick out developers that leave the team,
etc. So there would be two action items here: modify the code to support
SSH auth, add code that figures out the default app from the git remote to
this gem.
Heroku client works like this, it uses your SSH credentials to
authenticate. It also has the code to figure out the default heroku
application from git remotes, but that code is buried in the gem and is not
accessible unless you execute a command. This would need some refactoring
to pull out the default application name.
@geemus, what would you do?
On Thu, May 3, 2012 at 6:00 PM, geemus wrote:
> That does make sense. The way I usually do something like that is to set
> the rake task to just look for S3_BUCKET on my local machine as well and
> then each developer could just export the appropriate environment variable
> locally to make things work. You might want to namespace it a bit though,
> especially if you have multiple apps, to something like MYAPP_S3_BUCKET,
> just to avoid conflicts.
>
> That doesn't really answer the initial question though. I'm not exactly
> sure what the best way to find the default app in a case like that would
> be. Perhaps there should be a command that would output it, similar to how
> you can use `heroku auth:user` or `heroku auth:token` to make the client
> parse credentials and spit them out for you. Maybe something like `heroku
> apps:current` or something. Thoughts?
>
> wes
>
> On Thursday, May 3, 2012 10:48:47 AM UTC-5, dB. wrote:
>>
>> Take the example of a rake task that pushes a deployment to Heroku along
>> with some S3 assets. Every developer has their own heroku application, and
>> they configure it by creating a Heroku remote origin.
>>
>> To push to heroku a developer does do *git push heroku master*, then
>> they need to push some assets to their own S3 bucket (eg.
>> developer-bucket). The name of the bucket is configured as a S3_BUCKET
>> variable on their heroku application. Right now we execute 'heroku config
>> --long', parse that to figure out what the S3_BUCKET is, which is not
>> ideal. Nowhere the Rake task knows the name of the remote Heroku
>> application.
>>
>> Of course we could force every developer to hardcode the name of their
>> application somewhere on the client, but we might as well keep our heroku
>> config output parsing instead.
>>
>> Makes sense?
>>
>> On Wed, May 2, 2012 at 12:10 PM, geemus wrote:
>>
>>> I'd actually recommend checking out the heroku-api gem for programatic
>>> access. You can cover your example then this way:
>>>
>>> require "heroku-api"
>>> api = Heroku::API.new(:api_key => XXX)
>>> api.get_convig_vars("my-app").**body
>>>
>>> That said, I'm not sure what the best answer is on the default app
>>> front. Could you describe how you intend to use this information? I think
>>> that might help me narrow down a recommendation and/or fix it up to make it
>>> easier to do what you need.
>>>
>>> Thanks!
>>> wes
>>>
>>>
>>> On Tuesday, May 1, 2012 5:48:22 PM UTC-5, dB. wrote:
I'm trying to replace some code in a Rake task that executes 'heroku
config --long' and parses the output.
I can do this:
c = Heroku::Client.new(* Heroku::Auth.read_credentials)
c.config_vars("my-app")
Awesome, this returns the configuration variables for my-app as a Hash.
The next problem is how to figure out the default app name - in
development environments we often want to have our tasks run against our
"default" development Heroku instance. The code I want to call is in
lib/heroku/command/base.rb, extract_app_in_dir(Dir.pwd). There's
quite a bit of logic underneath this, storing git remotes and what not.
1. Do you think this should be refactored so that one can call
extract_app_in_dir without an instance of a class?
2. Is there a simple(r) way to get the default app name?
Thanks,
dB.
--
dB. | Moscow - Geneva - Seattle - New York
dblock.org -
@dblockdotorg
--
>>> You received this message because you are subscribed to the Google
>>> Groups "Heroku" group.
>>>
>>> To unsubscribe from this group, send email to
>>> heroku+unsubscribe@**googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/**group/heroku?hl=en_US?hl=en
>>>
>>
>>
>>
>> --
>>
>> dB. |
Re: Programmatic access to heroku with the Heroku Client gem
That does make sense. The way I usually do something like that is to set
the rake task to just look for S3_BUCKET on my local machine as well and
then each developer could just export the appropriate environment variable
locally to make things work. You might want to namespace it a bit though,
especially if you have multiple apps, to something like MYAPP_S3_BUCKET,
just to avoid conflicts.
That doesn't really answer the initial question though. I'm not exactly
sure what the best way to find the default app in a case like that would
be. Perhaps there should be a command that would output it, similar to how
you can use `heroku auth:user` or `heroku auth:token` to make the client
parse credentials and spit them out for you. Maybe something like `heroku
apps:current` or something. Thoughts?
wes
On Thursday, May 3, 2012 10:48:47 AM UTC-5, dB. wrote:
>
> Take the example of a rake task that pushes a deployment to Heroku along
> with some S3 assets. Every developer has their own heroku application, and
> they configure it by creating a Heroku remote origin.
>
> To push to heroku a developer does do *git push heroku master*, then they
> need to push some assets to their own S3 bucket (eg. developer-bucket). The
> name of the bucket is configured as a S3_BUCKET variable on their heroku
> application. Right now we execute 'heroku config --long', parse that to
> figure out what the S3_BUCKET is, which is not ideal. Nowhere the Rake task
> knows the name of the remote Heroku application.
>
> Of course we could force every developer to hardcode the name of their
> application somewhere on the client, but we might as well keep our heroku
> config output parsing instead.
>
> Makes sense?
>
> On Wed, May 2, 2012 at 12:10 PM, geemus wrote:
>
>> I'd actually recommend checking out the heroku-api gem for programatic
>> access. You can cover your example then this way:
>>
>> require "heroku-api"
>> api = Heroku::API.new(:api_key => XXX)
>> api.get_convig_vars("my-app").body
>>
>> That said, I'm not sure what the best answer is on the default app front.
>> Could you describe how you intend to use this information? I think that
>> might help me narrow down a recommendation and/or fix it up to make it
>> easier to do what you need.
>>
>> Thanks!
>> wes
>>
>>
>> On Tuesday, May 1, 2012 5:48:22 PM UTC-5, dB. wrote:
>>>
>>> I'm trying to replace some code in a Rake task that executes 'heroku
>>> config --long' and parses the output.
>>>
>>> I can do this:
>>>
>>> c = Heroku::Client.new(* Heroku::Auth.read_credentials)
>>> c.config_vars("my-app")
>>>
>>> Awesome, this returns the configuration variables for my-app as a Hash.
>>>
>>> The next problem is how to figure out the default app name - in
>>> development environments we often want to have our tasks run against our
>>> "default" development Heroku instance. The code I want to call is in
>>> lib/heroku/command/base.rb, ex**tract_app_in_dir(Dir.pwd). There's
>>> quite a bit of logic underneath this, storing git remotes and what not.
>>>
>>>1. Do you think this should be refactored so that one can call
>>>extract_app_in_dir without an instance of a class?
>>>2. Is there a simple(r) way to get the default app name?
>>>
>>> Thanks,
>>> dB.
>>>
>>> --
>>>
>>> dB. | Moscow - Geneva - Seattle - New York
>>> dblock.org -
>>> @dblockdotorg
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Heroku" group.
>>
>> To unsubscribe from this group, send email to
>> heroku+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/heroku?hl=en_US?hl=en
>>
>
>
>
> --
>
> dB. | Moscow - Geneva - Seattle - New York
> dblock.org -
> @dblockdotorg
>
>
--
You received this message because you are subscribed to the Google
Groups "Heroku" group.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en
Re: Programmatic access to heroku with the Heroku Client gem
Take the example of a rake task that pushes a deployment to Heroku along
with some S3 assets. Every developer has their own heroku application, and
they configure it by creating a Heroku remote origin.
To push to heroku a developer does do *git push heroku master*, then they
need to push some assets to their own S3 bucket (eg. developer-bucket). The
name of the bucket is configured as a S3_BUCKET variable on their heroku
application. Right now we execute 'heroku config --long', parse that to
figure out what the S3_BUCKET is, which is not ideal. Nowhere the Rake task
knows the name of the remote Heroku application.
Of course we could force every developer to hardcode the name of their
application somewhere on the client, but we might as well keep our heroku
config output parsing instead.
Makes sense?
On Wed, May 2, 2012 at 12:10 PM, geemus wrote:
> I'd actually recommend checking out the heroku-api gem for programatic
> access. You can cover your example then this way:
>
> require "heroku-api"
> api = Heroku::API.new(:api_key => XXX)
> api.get_convig_vars("my-app").body
>
> That said, I'm not sure what the best answer is on the default app front.
> Could you describe how you intend to use this information? I think that
> might help me narrow down a recommendation and/or fix it up to make it
> easier to do what you need.
>
> Thanks!
> wes
>
>
> On Tuesday, May 1, 2012 5:48:22 PM UTC-5, dB. wrote:
>>
>> I'm trying to replace some code in a Rake task that executes 'heroku
>> config --long' and parses the output.
>>
>> I can do this:
>>
>> c = Heroku::Client.new(* Heroku::Auth.read_credentials)
>> c.config_vars("my-app")
>>
>> Awesome, this returns the configuration variables for my-app as a Hash.
>>
>> The next problem is how to figure out the default app name - in
>> development environments we often want to have our tasks run against our
>> "default" development Heroku instance. The code I want to call is in
>> lib/heroku/command/base.rb, ex**tract_app_in_dir(Dir.pwd). There's quite
>> a bit of logic underneath this, storing git remotes and what not.
>>
>>1. Do you think this should be refactored so that one can call
>>extract_app_in_dir without an instance of a class?
>>2. Is there a simple(r) way to get the default app name?
>>
>> Thanks,
>> dB.
>>
>> --
>>
>> dB. | Moscow - Geneva - Seattle - New York
>> dblock.org -
>> @dblockdotorg
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "Heroku" group.
>
> To unsubscribe from this group, send email to
> heroku+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/heroku?hl=en_US?hl=en
>
--
dB. | Moscow - Geneva - Seattle - New York
dblock.org -
@dblockdotorg
--
You received this message because you are subscribed to the Google
Groups "Heroku" group.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en
Re: Programmatic access to heroku with the Heroku Client gem
I'd actually recommend checking out the heroku-api gem for programatic
access. You can cover your example then this way:
require "heroku-api"
api = Heroku::API.new(:api_key => XXX)
api.get_convig_vars("my-app").body
That said, I'm not sure what the best answer is on the default app front.
Could you describe how you intend to use this information? I think that
might help me narrow down a recommendation and/or fix it up to make it
easier to do what you need.
Thanks!
wes
On Tuesday, May 1, 2012 5:48:22 PM UTC-5, dB. wrote:
>
> I'm trying to replace some code in a Rake task that executes 'heroku
> config --long' and parses the output.
>
> I can do this:
>
> c = Heroku::Client.new(* Heroku::Auth.read_credentials)
> c.config_vars("my-app")
>
> Awesome, this returns the configuration variables for my-app as a Hash.
>
> The next problem is how to figure out the default app name - in
> development environments we often want to have our tasks run against our
> "default" development Heroku instance. The code I want to call is in
> lib/heroku/command/base.rb, extract_app_in_dir(Dir.pwd). There's quite a
> bit of logic underneath this, storing git remotes and what not.
>
>1. Do you think this should be refactored so that one can call
>extract_app_in_dir without an instance of a class?
>2. Is there a simple(r) way to get the default app name?
>
> Thanks,
> dB.
>
> --
>
> dB. | Moscow - Geneva - Seattle - New York
> dblock.org -
> @dblockdotorg
>
>
--
You received this message because you are subscribed to the Google
Groups "Heroku" group.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en
Programmatic access to heroku with the Heroku Client gem
I'm trying to replace some code in a Rake task that executes 'heroku config
--long' and parses the output.
I can do this:
c = Heroku::Client.new(* Heroku::Auth.read_credentials)
c.config_vars("my-app")
Awesome, this returns the configuration variables for my-app as a Hash.
The next problem is how to figure out the default app name - in development
environments we often want to have our tasks run against our "default"
development Heroku instance. The code I want to call is in
lib/heroku/command/base.rb, extract_app_in_dir(Dir.pwd). There's quite a
bit of logic underneath this, storing git remotes and what not.
1. Do you think this should be refactored so that one can call
extract_app_in_dir without an instance of a class?
2. Is there a simple(r) way to get the default app name?
Thanks,
dB.
--
dB. | Moscow - Geneva - Seattle - New York
dblock.org -
@dblockdotorg
--
You received this message because you are subscribed to the Google
Groups "Heroku" group.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en
