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 <wes...@heroku.com> 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 <wes...@heroku.com> 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 <http://www.dblock.org> -
>>>> @dblockdotorg<http://twitter.com/#!/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<heroku%2bunsubscr...@googlegroups.com>
>>> For more options, visit this group at
>>> http://groups.google.com/**group/heroku?hl=en_US?hl=en<http://groups.google.com/group/heroku?hl=en_US?hl=en>
>>>
>>
>>
>>
>> --
>>
>> dB. | Moscow - Geneva - Seattle - New York
>> dblock.org <http://www.dblock.org> -
>> @dblockdotorg<http://twitter.com/#!/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 <http://www.dblock.org> -
@dblockdotorg<http://twitter.com/#!/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
