3 ms·

A build tag can be used to rapidly go from a commit to a binary and from a deployment to a sha in cases where the build attribute isn't the sha, but a number or

by icefox 11y ago

A build tag can be used to rapidly go from a commit to a binary and from a deployment to a sha in cases where the build attribute isn't the sha, but a number or version. There are many other permission uses cases such as fine grain create and delete branch permissions. Only the release users should be allowed to create release/* branches. No one should be allowed to delete the 'master' branch. There are projects where I want to give developer access, but they are not allowed to create or delete any branch, they can only push new changes that are "finished". If they want to make a in progress branch they need to do it somewhere else.

sytse 11y ago
Isn't it possible to have developers tag the commit in this case? We already have the different between master and developer uses on protected branches. But it is an interesting idea to protect release/* and stable-* branches by default. The third paragraph is a bit of an edge case to me. Either you allow them to participate in non-protected branches or you have them work from a fork. Pushing changes is on the same level as creating branches to me.
- icefox 11y ago
  Binaries are built automatically these days using tools like Jenkins, Travis.ci, etc and not by developers. There are many ways to solve this problem such as the build bot making tags in a repository that isn't the main one, but suffice it to say developers are not making the binaries so using a developer account to push the tag from the build machine seems like a permissions bug and letting developers push tags also would risk someone accidentally deleting a tag or pushing a tag that is wrong or can't be reproduced by the build server. Another example is having a machine the mirrors a perforce, svn or other rcs. This bot will push up the mirror to a single branch called say 'svn-mirror'. You want to make sure that the mirror bot is the only one that can ever touch this branch. Again the mirror could be its own repo and no one else could be allowed to do anything, but users like to have the mirror along side the other main branches that they can push to. I can give you a dozen "edge case" examples, each of which I have seen not only desired, but required. Lack of fine grain permissions are one of the three reason why companies (not individuals) will abandon an existing Git server and replace it with an alternative. (See http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-build-git-server.html http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-bu... for my full writeup) And you can't say it is hard to implement either, these permissions are nothing but cascading ref based permissions. A user or group has permissions to read/write/delete a ref or ref regular expression. Honestly just copy what gitolite (which has no frontend so it constantly being passed over) does and you will be ahead of all of your competition. Add fine grain permissions to GitLab and I would recommend exploring going through the major hassle and pain of replacing Stash with GitLab, that is how valuable of a feature it is. Eventually Stash and the other Git servers will have this capability, might as well beat them to the punch and take some of their customers.
  - sytse 11y ago
    We use GitLab CI to build the binaries and push them. The binary build is triggered by a developer setting a tag. We want to integrate the mirror bot into GitLab itself, allowing you to track external repo's. We would love to have the permissions of gitolite if we can implement them without complicating the settings for users that don't need this. I would be happy to look at prototypes how to implement this in the UI (I'm @sytses on twitter). GitLab is open source, so if someone wants these advanced permissions the best way is to build them.

by icefox 11y ago

sytse 11y ago

Isn't it possible to have developers tag the commit in this case? We already have the different between master and developer uses on protected branches. But it is an interesting idea to protect release/* and stable-* branches by default. The third paragraph is a bit of an edge case to me. Either you allow them to participate in non-protected branches or you have them work from a fork. Pushing changes is on the same level as creating branches to me.

icefox 11y ago
Binaries are built automatically these days using tools like Jenkins, Travis.ci, etc and not by developers. There are many ways to solve this problem such as the build bot making tags in a repository that isn't the main one, but suffice it to say developers are not making the binaries so using a developer account to push the tag from the build machine seems like a permissions bug and letting developers push tags also would risk someone accidentally deleting a tag or pushing a tag that is wrong or can't be reproduced by the build server. Another example is having a machine the mirrors a perforce, svn or other rcs. This bot will push up the mirror to a single branch called say 'svn-mirror'. You want to make sure that the mirror bot is the only one that can ever touch this branch. Again the mirror could be its own repo and no one else could be allowed to do anything, but users like to have the mirror along side the other main branches that they can push to. I can give you a dozen "edge case" examples, each of which I have seen not only desired, but required. Lack of fine grain permissions are one of the three reason why companies (not individuals) will abandon an existing Git server and replace it with an alternative. (See http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-build-git-server.html http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-bu... for my full writeup) And you can't say it is hard to implement either, these permissions are nothing but cascading ref based permissions. A user or group has permissions to read/write/delete a ref or ref regular expression. Honestly just copy what gitolite (which has no frontend so it constantly being passed over) does and you will be ahead of all of your competition. Add fine grain permissions to GitLab and I would recommend exploring going through the major hassle and pain of replacing Stash with GitLab, that is how valuable of a feature it is. Eventually Stash and the other Git servers will have this capability, might as well beat them to the punch and take some of their customers.
- sytse 11y ago
  We use GitLab CI to build the binaries and push them. The binary build is triggered by a developer setting a tag. We want to integrate the mirror bot into GitLab itself, allowing you to track external repo's. We would love to have the permissions of gitolite if we can implement them without complicating the settings for users that don't need this. I would be happy to look at prototypes how to implement this in the UI (I'm @sytses on twitter). GitLab is open source, so if someone wants these advanced permissions the best way is to build them.