That is, can I have a Stash-hosted git repository flow changes through gerrit?
I think the answer is 'no' but thought I'd ask.
Hi Brian,
That really depends on Gerrit. If you can configure it to push changes after a review to another Git server, there shouldn't be any reason why that destination couldn't be Stash. This looks like it might be useful:
http://gerrit.googlecode.com/svn/documentation/2.0/config-replication.html
Of course, being a Stash developer, I'd also suggest trying out our (awesome) Pull Requests which we introduced in 1.3, which I think would be roughly equivalent to Gerrit reviews. ;-)
Cheers,
Charles
Charles,
Thanks for the link. I gave the stash pull requests feature a test drive today. It's heading in the right direction. We are developing on feature branches which are delivered into release windows at which time they roll into master if their release criteria is met. It seems like the stash pull request fits part of this. What I really need to be able to do is select a collection of feature branches and see if they merge/build together with the ability to change the feature set as business needs change over time. I'm not quite sure how to implement this up yet.
Brian
That's a tricky one. Sounds like you need to regularly create/destroy temporary branches and possibly run a build against the result. You could certainly write a script to do that, and run it every day/week/whatever. There is obviously the change of multiple merge conflicts. If you created pull requests to a release branch, Stash will certainly keep track of the merge state for each one, but doesn't really give you a way to 'administer' them as a collection; that's not really their purpose. I'm afraid I haven't had enough experience with Gerrit to comment on whether it would be better at that or not.
Let me know if you find something that helps with this workflow. We're always on the look-out on how to improve/extend Stash to help with different business requirements.
Thanks Charles,
Yes, it currently seems that our build process will need to use on-the-fly temp branches and merge/build.
Here is a blue sky thought -- What if Jira issues know how to branch themselves in git and assume they are developed on feature branches, one issue/branch. Then, when a developer starts working on an issue, Jira and Stash know how to setup that branch. Jira also knows what issues are targeted for a given release given the Jira roadmap. A plan in Bamboo could then be to take all the Jira feature branches for a given release and merge/build them. The sticky part is when merge failures occur. Rerere would need to be worked into the workflow to address that.
It looks like you're new here. Sign in or register to get started.
