We are currently evaluating whether we could replace Crucible by Stash and its Pull Request feature. So far, Stash's ability to create pull requests in combination with its Branching Model looks very promising.
However, we stumbled upon some issues. While we were able to get around some of those at least partially - for instance, by installing the Stash Auto Unapprove Plugin - we still face the following two issues:
- Developers should be forced to work with pull requests. Thus, directly pushing to the main development, or even to the production branch, should be preventable. Instead, changes should go into those branches via pull requests from (for instance) feature branches.
- Currently, new commits to a branch (for instance, feature branch) that is involved in an open pull request (for instance, from that feature branch to the main development branch) are automatically added to that open pull request.
While the first issue is already addressed in STASH-2910, the second one gives us a headache:
We have feature branches that typically live for a couple of days (up to one or even two weeks - they are created via Sories in JIRA Agile). At the same time, we encourage developers to push their daily changes every evening to enable reviewers to give swift feedback on that daily work. This again allows developers to incorporate important feedback as soon as possible (particularly, not only at the end of the Sprint).
Ideally, the reviewer would approve such an pull request immediately. However, sometimes the review reveals weak spots and the developer would have to make smaller fixes. For such fixing commits, it is absolutely fine to be automatically added to the open pull request - because these commits affect aspects that are already part of the pull request. In Crucible, the developer would explicitly add these commits to the ongoing review (via smart commits - how cool is that?).
Beyond that, frequently there are new commits that add new aspects, too - just because the story is not yet completed and thus being developed in the said feature branch and pull request, respectively. In this case, these commits should not be automatically added to the open pull request. Instead, they should be addressed in a new pull request that would explicitly cover the new aspects. In Crucible, such new commits would be added to a new review but not the an existing one.
Finally, here comes the question: Is it possible in some way to prevent Stash from automatically adding new commits to open pull requests? As you might have guessed already, the Stash Auto Unapprove Plugin partially solves this issue by at least setting the open pull request back to state "unapproved". However, this does not solve the problem that currently new aspects slip into reviews although they should be discussed in separate reviews.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.