You've lost me a little here.  `heroku releases` gives you all the deployed git 
versions and other changes.  For instance:

Rel   Change                          By                    When
----  ----------------------          ----------            ----------
v214  Deploy 5f3f619                  neil.middle...@gmail.com    2012-04-18 
17:28:41 +0100
v213  Deploy b71ce95                  neil.middle...@gmail.com    2012-04-12 
15:04:45 +0100
v212  Deploy d27f151                  neil.middle...@gmail.com    2012-04-12 
13:20:53 +0100
v211  Deploy 6b81eef                  neil.middle...@gmail.com    2012-04-12 
12:59:28 +0100
v210  Config add FACEBOOK_APP_SECR..  neil.middle...@gmail.com    2012-04-12 
12:56:11 +0100
v209  Deploy 2f54f24                  neil.middle...@gmail.com    2012-04-12 
11:43:28 +0100
v208  Deploy 19b486d                  neil.middle...@gmail.com    2012-04-12 
11:36:34 +0100
v207  Deploy efdd6ef                  neil.middle...@gmail.com    2012-04-12 
11:22:40 +0100

Each of those deploy hashes under 'Change' match commits in my Git repo on 
Github (and everywhere else).

By rolling back to say v208 I know I'm going to end up with 19b486d, or am I 
missing something obvious here?

N


Neil


On Monday, 23 April 2012 at 02:08, david ignacio wrote:

> Hey-
> 
> So one thing that has got me about heroku is that there isn't
> necessarily a good link between the git repo and heroku releases. By
> this I mean that it isn't entirely obvious what is deployed and
> running at the moment. There are two current tools we have:
> * the heroku remote in the git repo
> * heroku releases
> 
> This gives me the current release and what is working right now, but
> nothing more. If I deploy something broken, there isn't a clear way
> to find what I'd be rolling back to. The hashes displayed in heroku
> releases are of the compiled slugs.
> 
> I have gone through a few back and forths as to what would be a good
> way to fill this gap. I realized that you'd really need two different
> scripts since releases are created in multiple places, one in the
> heroku cli and one in git. The config/addon changes trigger a new
> release to be created, but I think that those changes are well
> documented in heroku releases. It was the git-push triggered releases
> that I wanted to track.
> 
> This led me to write: https://github.com/deignacio/gthr
> 
> What I'm wondering from you guys is:
> * is there any other way in heroku that I can get the information I'm
> scraping so that I'm not just scraping stderr of git push?
> * am I thinking about this problem in the right way that this
> solution seems okay?
> * are there any other precedents that I didn't find in my sanity
> check google search?
> * assuming that the previous questions are positive, can anyone think
> of any other things they'd want?
> 
> Thanks for your input
> Dave
> 
> -- 
> 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 
> (mailto:heroku+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/heroku?hl=en_US?hl=en
> 
> 


-- 
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

Reply via email to