-
Suggestion
-
Resolution: Won't Fix
Use case:
http://vim-wiki.mawercer.de/wiki/index.html\\
worked fine with github: use a small script to sync online edits with github repository.
For (least priviledge) reasons it would be nice if the same could be done @ bitbucket:
Create a new key which only gets write access to https://bitbucket.org/vimcommunity/vim-git-wiki so that online changes can be pushed automatically.
Deployment keys get close: They allow to upload a key and associated it with one repository only. But you cannot push. Thus I recommend extending deployment keys adding an option allowing the user to choose between read only (current behaviour, should be default) and (rw, opt-in) - for some special use cases like mine
Of course I could create a new user and grant access to the repository. However I feel that's overkill.
I talked to Jesse Yowell (support) who suggested me creating a ticket (BBS-7401)
Marc Weber
[BCLOUD-8873] Extend deployment keys to allow both: read/write
Same here.
Need to be able to push tags from build server without having to create a full user account. Looking at other providers to replace Bitbucket / Jira etc.
Don’t need full write, only tags.
In our new build process we will need to push tags too. Looking at other providers now.
+1 on pushing tags. For us, the deployment key shouldn't push anything more than the tags.
+1 on this. Seems silly not to. Charge me a special rate for deployment keys with the ability to push tags. Not a full user mind you. Just existing functionality + pushing tags.
Adversely affecting billing is the wrong reason to deny a useful feature.
We were originally using Team-level keys in our setup, but then BitBucket decided to deprecate that feature, and told us to use Deployment keys instead. Unfortunately, we don't adhere to the "accepted development approach" that BitBucket seems to be built around where each developer works from his/her own machine. We also have shared server-based development machines in our workflow, and Team-level keys worked great with this. We've attempted to switch to Deployment keys as much as possible, but this continues to be a barrier for us. I suppose we can assign a developer-level key to each affected server, but isn't that bending the rules? That was actually the advice given to use by Support, but it doesn't sit well with me. I guess we're left with no choice, though.
Ye having a deploy key "Deploy user" that cant push back the tag is pretty pointless and breaks the concept of CI. I don't understand how this wasn't a given when it was planned...
exactly. creating a tag is all a deployment key should be able to write.
+1
as you can't vote on closed issues, please vote on BCLOUD-11266 instead.