which is the current repo for this gem? #4
Comments
|
IIRC I have merged in all of technicalpickles stuff into master, I just don't think he ever pushed the new gem. He set it up so I can't... You should be able to confirm that by looking at the network. LMK if you need more help. I'd look but I'm swamped. Alan On Mar 19, 2012, at 4:38 PM, Jonathan Rochkind wrote:
|
|
Thanks! I'm confused by your response though -- technicalpickles is On Mar 19, 2012, at 4:53 PM, Alan Pinstein wrote:
|
|
So, mine is the canonical, but technicalpickles forked mine and published that to RubyGems before we got in touch with each other. Madness has ensued. I worked with him months ago to merge in all of his changes and also fixed some bugs. They are all on my repo. You can see this from the network view: https://github.com/apinstein/git-deployment/network I have just been using the gem via git URL so it hasn't bothered me to not have the latest gem on RubyGems. We both have lots of watchers and forks. I guess he isn't up to working on this anymore though... Unfortunately he renamed his repo, which complicates things. I am scared to rename my repo as so many people depend on the old name. I will see if he can add me to the RubyGems so at least I can update that gem. Frankly I am a little scared to update it because a bunch of stuff has changed and so many people depend on it for deployment. I couldn't easily handle an onslaught of support requests if there were a problem. What is your goal anyway? I am not sure what you're trying to achieve. Alan On Mar 26, 2012, at 8:52 PM, Jonathan Rochkind wrote:
|
|
Yeah, I might be better of making own fork, copy and pasting code from you at the moment. My goal is I'm actually NOT interested in 'flow' from staging to production, or even multi-stage cap at all (emphasize: YET). But I AM interested in a cap task that automatically adds a tag to my git repo, say, deploy-yyyy-mm-dd-x. It turns out that doing even just that in a robust and foolproof way is a bit tricky -- and you've solved that problem very nicely as a subset of everything else you did. So, I dunno, the question is about refactoring your code to allow optionally just the git tagging piece. It hypothetically makes sense for your package to allow just git tagging, and then later someone could 'upgrade' to the complete multistage flow with tagging. But if it's too hard to refactor your code to do that without potentially breaking something, perhaps I should just copy-and-paste what you've figured out into my own thing that just does tagging. Either way, i'd encourage you to bug technicalpickles to get gem release rights. Eventually there's going to be a bugfix or feature you need to release. And possibly then release a patch version of the gem that has no changes except pointing to your repo as the home page in the gemspec, so that'll show up on rubygems.org. Right now, it's a multi-hour process just for a developer to track down where the canonical repo and potential maintainer is (you know, in case you want to actually try to check with them before forking, renaming, and releasing your own gem, to be polite, heh. Or just to know which repo to fork from to get up to date code!) |
|
Ah well in that case you should probably get away with copy/paste rather than refactoring. If you end up with a nice library then maybe we could refactor capistrano-gitflow to use YOUR tagging lib. I think it will be easier for you that way. In the meantime I'm trying to get RubyGems rights. Alan On Mar 27, 2012, at 3:58 PM, Jonathan Rochkind wrote:
|
|
Thanks! I'd encourage you to release a new version with your bugfixes once you While pointing directly to the git repo in the Gemfile mostly works, Also, I would have had no idea that I should be pointing directly at Anyhow, thanks for the cool code! On Tue, Mar 27, 2012 at 4:28 PM, Alan Pinstein
|
|
Yes, agree on all points! Enjoy. LMK if you get a lib set up for tagging. On Mar 27, 2012, at 5:35 PM, Jonathan Rochkind wrote:
|
|
hey, so I'm doing that thing, it's basically ending up pretty easy to add the functionality of this thing in too, but based on a refactored codebase. Kind of having fun with it, in the minutes here and there I find to work on it. (And the stuff figured out in your code on proper git command line invocations to get what we want is crucial, it would not be fun if you hadn't figured that out for me already!) Question about desired features. Your documentation still says tags will be "production-yyyy-mm-dd.x", but your code does a fancier template with (interactively entered) short description, account name of person doing the deploy, etc. How important do you think this fancier template is to your users, or how important is it to you? Should I bother implementing it? (If I do, I might do something clever with a configurable format template string or something). update: oh, and when/if I'm finished, happy to make you a committer on the code/releaser on the gem if you want. |
|
oh, and same thing for the feature to show the commit log and force interactive accept before doing a production deploy. Has that worked out as useful as you anticipated, do you think people like/need it? Is it worth adding it to my refactored version? (In my version, pretty much EVERYTHING will be easily configurable to turn it off or on and use what bits you need; but I'll also provide some optional 'requires' to give you out of the box standard workflows, including one as close to what your code does as I can or feel like getting. Is the plan anyway.) |
cool! definitely most of the work was in the git-fu! I was doing a bunch more git-fu today for our migrations system. We don't allow migrations to run out-of-order thus when switching between feature branches things get sticky trying to juggle migrations, so I wrote a script that runs as a git post-checkout hook to figure out how to solve the problem whenever you switch branches. Here's a link if you think any of it would be useful for you: https://github.com/apinstein/mp/blob/githook/VCSHelper.php#L200
Docs are out-of-date. We do like the auto-naming stuff; making it work off of a template would be cool. We found over time that having something more descriptive after the unique prefix is really helpful when scanning lists of tags for things. Alan |
|
Oh yeah I love that. It prevents us from pushing without remembering to look at what we're pushing! Alan On Apr 5, 2012, at 6:48 PM, Jonathan Rochkind wrote:
|
|
How about the "serial number" included in tag that seems to increment every time you do a new deploy? That's harder to implement while also allowing a configurable template for the tag. Is that actually important to your use case? |
|
yes, it's very important, and frankly should be for you, too. it's what makes the tags sort in date order when sorted lexicographically. On Apr 9, 2012, at 10:54 AM, Jonathan Rochkind wrote:
|
|
hmm, I don't understand, if you're tagging eg But maybe I'm having trouble what's going on in general. Can you explain what the git commands in last_tag_matching actually do? Esp change at c0ac685 In my version of git, there's no |
|
git tag -l 'production*' That sorting is critical to the code being able to find tags based on dates. On Apr 9, 2012, at 11:55 AM, Jonathan Rochkind wrote:
|
|
git tag -l 'production' is NOT what your code seems to do, right? It does this that I don't understanding (passing literal backtics to git, what?) But yeah, Is the issue only when you have two tags that have the same yyyy-mm-dd, you need to be sure which came second? What if I can get git to actually give a list sorted chronologically by when the tag has been applied, would that eliminate the need for lexicographic sorting matching chronology, or would it still be needed? |
Well even with git describe you want them to be date-sorted, and it's the same problem. I suppose you could move the date sorting into ruby but then it'd have to do more work to get all the tags and parse them.
Yes that's the point.
Could work though frankly that might be tricky, too. I am actually not sure the data is even there. Remember people on different machines might be doing the tagging....
|
|
looking into it, the date the tag was made IS in git, so long as it was an 'annotated' tag (with -a and/or -m), not a 'plain' tag. Not sure if time out of sync on different machines will be a problem though. As a real user, have you had that issue in real life where different developers on different machines are tagging staging-* or production-* tags near simultaneously? (seems like that could be a race condition even with your current code, if it's done in just the 'wrong' sync order). Sorting based on actual date-of-tag is definitely a lot simpler. Other than the possibly-not-likely issue of developers near-simultaneously tagging, are there other cases where you'd want something OTHER than the actual most recent tag matching 'staging-*'? Like someone tags a tag beginning 'staging-' , but it intentionally sorts lexicographically not most recent, and it's NOT meant to be the next deploy? |
|
I also can't figure out how your current code works at all or what it's intended to do, and it does NOT work on my machine at all, so one way or another I've got to do something different in my version. |
|
I am not sure.... There are a ton of users of this system; perhaps a poll to the user base would be better? Unfortunately this was a side-project and I didn't TDD it so there are really no specs other than the code itself. Sorry I wish I could help further I just don't have tons of time. Alan On Apr 9, 2012, at 1:40 PM, Jonathan Rochkind wrote:
|
|
no prob, i'll do what makes sense to me, and do something, and see if anyone other than me wants to use it (if you wanted to use what i end up with, assuming I ever finish, and/or wanted to be a committer on it, and/or wanted to call it the next version of gitflow, I'd be overjoyed, but if you don't, no problem, it'll just get a new name and be my thing). I have no idea how one would go about polling all the potential users of the thing anyhow! If I release and then find out someone needs mine to do something different than it does, I'd see if I could make it do that, if I had time and could figure out how, of course. |
|
Fair enough. Good luck! On Apr 9, 2012, at 1:59 PM, Jonathan Rochkind wrote:
|
|
It's intentional that when you promote a staging tag to production, you don't create a new yyyy-hh-tag, it re-uses the exact timestamp etc from staging? So if your last staging tag was on March 1, and you're promoting it to production on march 10, the production tag will still look like "production-2012-03-01-ETC". I understand that right, and it's intentional? |
|
Yes, it was intentional at the time so that you could easily tell corresponding staging and production tags. I am not sure if it's needed if there were a utility to help show deploy history. I am also not sure how that works now that tags have suffix labels. Sent from iPhone. On Apr 9, 2012, at 6:24 PM, Jonathan [email protected] wrote:
|
|
okay, thanks. Based on your response, I'm leaning toward re-formulating the tag for production:
Sadly, the opposing argument is: in your current code you're prompted to add the 'what' only for staging, and it makes sense to copy that 'what' over to production, not abandon it or require it to be entered again. Sigh. Well, nothing's perfect. I'll do what I can and see if anyone other than me wants it! |
|
oh, I'm also adding a 'show_tags' option that will show you the last X production or staging tags WITH commit messages, to make it easier to see exactly what dates they were actually tagged, who tagged em, and what the commit message was. But I'm still not entirely happy with losing the previously interactively entered 'what' on the staging tag when you retag for production. sigh. |
|
Okay, I got kind of obsessed on this stuff and worked on it when I should have been working on other things, heh. It was a fun little puzzle. I have a gem that I think is pretty cool -- basically refactored version of what you're doing to be much more flexible. It does some things differently though, and lacks a couple of potentially important features that you've got. (It's probably got a couple edge case bugs I don't know about yet hiding in there somewhere too, I'd imagine) Check it out if you have time: If you wanted to take it for a test drive and give me feedback, that'd be awesome. It's not actually released as a gem to rubygems yet, but I can do so if that would make it easier for you to test. If you have no time, that's cool too. If you're interested in being a committer/gem-releaser on my code, happy to make you such. For the couple potentially important things my version does not do, see the "To Be Done" section of the readme -- it definitely doesn't support the tag formats the way you want at the moment (it hypothetically could, but it's a bit tricky, and I don't personally need/want them so not sure when/if I'd get to it). Would be happy to get feedback, critique, suggestions, whatever! Also fine if you have no time for such. |
|
For what it's worth, I added @apinstein as a collaborator/owner on the rubygems sometime shortly after the last message in thread. |
|
We no longer use this project internally; we’re doing something similar but different. y’all do whatever :)
|
|
Currently capistrano-gitflow supports now capistrano 3 also. If anyone is interested i can submit a pull request here to merge changes from capistrano-gitlflow into this repository also. Let me know please what you think. |
I'm getting confused, seeing which one I get an answer on.
There's this repo, and there's https://github.com/technicalpickles/capistrano-gitflow , which is a fork of this one.
This one has more recent commits than technicalpickles, and is identified as github as the 'original'.
However, the gemspec for the latest release on rubygems points to technicalpickles. As exposed by 'homepage' link on https://rubygems.org/gems/capistrano-gitflow
So what's up, which is repo has the latest code matching current gem release, and who, if anyone, is actually the maintainer/committer?
Thanks!
The text was updated successfully, but these errors were encountered: