Well that's embarrassing. Looks like when I found the need for this, I had several issues in my repo/app running in concert. This made me think that when the hashes listed in `heroku releases` differed from both `git log heroku/master` and `git log master` that I was perhaps seeing an alternate hash generated by the slug compilation.
Don't mind me I guess, at least I only spent a day or so on this script, although I think that perhaps then converting the idea into a heroku cli plugin that just took the versions in releases and created the tags as scraped could still have value? Thoughts? On Mon, Apr 23, 2012 at 09:10, Neil Middleton <[email protected]> wrote: > 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 [email protected] 2012-04-18 > 17:28:41 +0100 > v213 Deploy b71ce95 [email protected] 2012-04-12 > 15:04:45 +0100 > v212 Deploy d27f151 [email protected] 2012-04-12 > 13:20:53 +0100 > v211 Deploy 6b81eef [email protected] 2012-04-12 > 12:59:28 +0100 > v210 Config add FACEBOOK_APP_SECR.. [email protected] 2012-04-12 > 12:56:11 +0100 > v209 Deploy 2f54f24 [email protected] 2012-04-12 > 11:43:28 +0100 > v208 Deploy 19b486d [email protected] 2012-04-12 > 11:36:34 +0100 > v207 Deploy efdd6ef [email protected] 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 > [email protected] > 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 > [email protected] > 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 [email protected] For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en
