1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


Issue #8873 wontfix

Extend deployment keys to allow both: read/write

created an issue

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

Comments (14)

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

  2. anbuckim

    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.

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

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

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

  6. Log in to comment