-
Suggestion
-
Resolution: Done
Hi everyone,
Thanks for voting and commenting on this suggestion. Your input in the comments helps us understand how this affects you and what you're hoping to accomplish with Stash.
This suggestion is a priority for the Stash development team and is on our roadmap, however we're not able to provide a timeline for when it will be resolved.
Product feedback is collected from a number of different sources and is evaluated when planning the product roadmap. You can learn more about our process here.
Cheers,
Roger Barnes
Product Manager - Stash
Original request description:
Forcing all merges to a certain branch (except for key people) to go via pull requests is currently possible in branch permissions.
Pull Requests give traceability and the option to comment on code being merged in - in addition, developers can use plugins and merge checks to add additional controls and warnings to the Pull Request page.
This means that automated checks can be added as merge checks and the people that can be allowed to merge is greater than those who can push - a pre-receive hook doesn't allow good feedback or warnings to the user (as well as not having the context of the branch being merged in, the author etc), so allowing only a restricted set of users to push but allowing all to merge a pull request is desirable.
- is duplicated by
-
BSERV-3700 Branch Permissions for Pull Requests
-
- Closed
-
-
- Closed
-
- Closed
-
- Closed
- was cloned as
-
- Closed
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[BSERV-2910] Allow merging via pull request but disallow pushing directly to branch
Bradley Baetz
added a comment - STASH-5009 looks like its for access keys (presumably because you can't pick access key users from the UI). My requirement is different (our CI server uses https, so is a "real" user, plus we have release management teams that get to commit directly too) I'll open a new feature request later today for this - until then I'll have to keep using our own custom plugin for this.
Bradley Baetz
added a comment - STASH-5009 looks like its for access keys (presumably because you can't pick access key users from the UI). My requirement is different (our CI server uses https, so is a "real" user, plus we have release management teams that get to commit directly too) I'll open a new feature request later today for this - until then I'll have to keep using our own custom plugin for this. bradley.baetz I believe your use case would be covered by implementing the suggestion described in STASH-5009.
Bradley Baetz
added a comment - felix.haehnel - is there already a separate feature request to make this a more fine-grained permission, or should I create one? (Use case is having Jenkins run release builds and updating the pom.xml, but not letting anyone else push directly to the release branch)
Bradley Baetz
added a comment - felix.haehnel - is there already a separate feature request to make this a more fine-grained permission, or should I create one? (Use case is having Jenkins run release builds and updating the pom.xml, but not letting anyone else push directly to the release branch) bradley.baetz - It is a per-repository/branch option that will disallow directly pushing for everyone.
Bradley Baetz
added a comment - fhaehnel - Is that a per-repository/per-branch option, or can it be set up with certain users that can bypass this restriction (eg to allow Jenkins to commit to master directly, even though "regular" users can't)
Bradley Baetz
added a comment - fhaehnel - Is that a per-repository/per-branch option, or can it be set up with certain users that can bypass this restriction (eg to allow Jenkins to commit to master directly, even though "regular" users can't) This is now possible in Stash with branch permissions. The option "Prevent changes without a pull request" is available starting with version 3.10.0.
Hi all,
I managed this topic with a hook.
I did little changes in https://bitbucket.org/atlassian/stash-example-hook-protect-ref.git and now I'm able to prevent any push to master and release branches.
It is only possible to merge via pull requests.
But an implementation in Stash will be better for all of us.
This ticket was opened on 9/Dec/12. Doesn't look like it will be implemented anytime soon. Could you please provide an ETA on when these will be resolved. We are waiting for these 'critical' updates for a very long time. Thanks.
david.humeniuk@udri.udayton.edu
added a comment - @Michael. I'm referring to the branches that have been configured to be protected by by your plug-in. If I've configured the ref/heads/development branch to be protected as well as all integration branches (ref/heads/integration/*) with your plug-in, then in our scenario, it would be okay to merge development into any integration branch. I guess you couldn't just allow any protected branch because merging an integration branch into development without a pull request would not be okay. I guess it would be more complicated, but basically I want to allow merging of branches to catch it up with already committed code. For us, the workflow looks like this:
feature (-> integration) -> development -> master (integration branch is optional)
So typically feature branches are merged to integration, then to development, then to master (through pull requests, except for dev to master). However, I would like to allow merging without a PR in the other direction.
david.humeniuk@udri.udayton.edu
added a comment - @Michael. I'm referring to the branches that have been configured to be protected by by your plug-in. If I've configured the ref/heads/development branch to be protected as well as all integration branches (ref/heads/integration/*) with your plug-in, then in our scenario, it would be okay to merge development into any integration branch. I guess you couldn't just allow any protected branch because merging an integration branch into development without a pull request would not be okay. I guess it would be more complicated, but basically I want to allow merging of branches to catch it up with already committed code. For us, the workflow looks like this:
feature (-> integration) -> development -> master (integration branch is optional)
So typically feature branches are merged to integration, then to development, then to master (through pull requests, except for dev to master). However, I would like to allow merging without a PR in the other direction.
Created https://jira.atlassian.com/browse/STASH-7475