I'm beginning to suspect that this is not possible. I was hoping that I could set up custom access control in Gerrit so that a particular role (defined in TF) would not have read access to a specific branch in a repo.
However, it appears that users with this role are unable to clone the repo at all. I was hoping they'd be able to clone and just not beb able to check out the restricted branch.
Just wondering if anyone else has enountered this and might be able to confirm the behaviour I'm seeing. I did see another thread here recommending gitolite for partial copies but I'm restricted to using TF/Gerrit.
Thanks!
Related
I would like to push build tags to a non-standard location on gerrit, mainly to avoid them from showing up as an official tag and also to avoid polluting users with a bunch of build tags.
On old versions of gerrit, I was able to grant myself permissions to create refs and tags in, say, refs/builds/tags/*, and then do
git push origin refs/tags/BUILD-123:refs/builds/tags/BUILD-123
The beauty of the scheme is that this way, the build tags don't pollute ordinary users' git repos, but if someone is interested in the build tags, they can run:
git fetch origin 'refs/builds/tags/*:refs/tags/*'
and then all the build tags appear and become usable as tags.
It seems that on newer versions of gerrit (2.16?) direct push is limited to the standard locations.
It also appears as if one can only push tags of commits which are direct ancestors an existing branch, so if my build does anything unusual (for example rebase to the tip), it fails.
Is this configurable anywhere?
It turns out there is no such restriction, you just have to grant yourself all the required permissions, like so:
[access "refs/builds/*"]
create = <me>
createSignedTag = <me>
createTag = <me>
delete = <me>
read = <me>
I forgot to give myself read permissions...
The restriction that does exist is where you cannot push a tag that is not for a commit that is an ancestor of an existing known branch. The reason this restriction exists is because access to commits is controlled via ACLs that feature wild carded refs as primary key to permissions. If someone knew a "forbidden" sha and was allowed to push a tag, this scheme can be bypassed.
The trick is to give up on pushing tags and to push branches instead. Branches can be pushed to non-standard locations just like tags, and if someone fetches them into refs/tags, they also act like lightweight tags.
We have a Github organization, which is broken into teams.
I want to use Jenkins github plugin to just scan my teams folder, is this possible?
So far I can only get it to scan the whole org which has thousands of repos in it, or scan my user which also picks up other repos outside the team.
I have tried scanning for <ORG>/teams/<TEAM> but Jenkins seems to think that is a user and looks in the user api rather than org.
I know I could use a repo name filter, but currently the repos dont have a standard enough name to do that on and renaming them would be a pain as all links and clone would need updating.
Any help most appreciated.
How can I enable auto fork syncing on BitBucket cloud ? I cant find the option and have to manually keep the fork updated.
Thanks!
While originally I found this article, it seems this only applies to their server product: https://confluence.atlassian.com/bitbucketserver/keeping-forks-synchronized-776639961.html
This article indicates that its a process you will need to manage manually on local:
https://confluence.atlassian.com/bitbucket/forking-a-repository-221449527.html
After you fork a repository, the original repository is likely to continue to evolve as other users commit changes to it. These changes do not appear in your fork. However, you can pull these changes into your fork later by syncing changes locally from the command line.
While this describes pulling upstream manually, you could probably script something to do this more automatically for your purposes. If I end up doing something like this for our team, I'll update this answer with more details or perhaps someone else will do the same.
I'm looking for a way to automatically add +2 permissions for certain refs for a lot of projects in Gerrit and unfortunately it seems there are no API calls to modify access rights, only to read them. Do you have any idea how to modify refs permissions for a big amount of projects?
I'm using Gerrit 2.9.
Thanks.
One possibility would be to create a batch script to modify the project.config for those projects and commit them back to gerrit.
This is how you can checkout the project.config for the All-Projects, it works the same for other projects: http://blog.bruin.sg/2013/04/how-to-edit-the-project-config-for-all-projects-in-gerrit/
Simply put:
Create list of project you want to change
Iterate over the lest
Checkout the refs/meta/config ref
Use script to modify project.config
Commit and push back to the server
More information about the project.config: http://gerrit-review.googlesource.com/Documentation/config-project-config.html
I have been evaluating it for some time, testing different scenarios and trying different configurations. During this time, I have deleted and recreated my repositories a number of times. Each time, I have had to go back and reassign all of the permissions to each repository.
Currently, I have decided to use a single repository for common code, and then a separate repository for each product that will be produced.
Now, I am just about to take the leap and start using Plastic SCM in earnest. But before I do that, I have a question: is there a way to inherit/assign permissions on a repository from another repository? E.g. I set up all permissions on 'Repo A', and then inherit/assign those same permissions on 'Repo B'.
I am sure that I will be adding more repositories as we produce more products, and I would like to find the easiest way bring them online.
You can define a set of permissions for the repository server by right clicking a repository and clicking on Repository Server permissions:
Then all the repositories will inherit permissions from the repository server.
Hope it helps.