Extend deployment keys to allow both: read/write

Issue #8873 wontfix
marco-oweber created an issue

Use case:
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

Comments (16)

  1. Brian Nguyen


    We have been asked to do this before (#6887), however we decided that allowing a deploy key to have write permission would adversely affect our billing.


  2. Gergely Risko

    Hmm, I'm just saying that in the long run behaving like this with customers will definitely "adversely affect your billing"...

    I know I'm talking to engineers and you are not the decision makers, so will just leave this message here, no need to answer.

  3. a

    It would be great if we could have write-access deploy keys even if we're charged extra for it or if it's treated as another user in our billing.

  4. Dan Gibson

    I wouldn't mind paying for it either... Good business practice: If someone wants to give you money, you should take it. Anyone agree?

  5. bailz777

    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...

  6. Ted Wood

    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.

  7. Phil Austin

    +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.

  8. Log in to comment