We recently migrated to GitLab Self Hosted (V14.3.0)
We migrated 100+ repos to Gitlab and then we realized, by default only maintainers have write access to Gitlab protected branched.
Is there a way to change the following setting in one shot for multiple repositories or we will have to manually change for every repository?
We want to change "Allowed to merge" from "Maintainers" to "Developers + Maintainers"
In the main group we have set it to the following, I was hoping that this will make it work but no luck -
Well manually will be a bad approach, but the GitLab API offers a lot of functionality regarding that problem. I will not write the script, but i will outline you the APIs you can use and why you use them.
Fetch a list of all projects you want to change - the Projects API
GET /projects
With this endpoint you will receive a list of all the projects within you instance, on which the user has access - be aware that this is a paginated request - so just calling it once will not be sufficient.
Adapt the Protected branches - the Protected Branches API
With the project IDs from the first part you can now query each project and change the protection. We ended up with first deleting the protection and recreating them, because it has proven to be easier.
Anyway i recommend to automate this with a script, and do it rather sooner than later. As some projects might start with custom protections, and this can make the migration harder.
the GitLab API offers a lot of functionality regarding that problem
Actually, GitLab 15.6 (November 2022) does provide said API:
Update access levels from Protected Branch API
Previously, the UI was required to update the access levels of protected
branches. The API required you to unprotect, then reprotect, a branch when
updating its access levels.
Now, the
protected branches API
enables you to directly update which users or groups are allowed_to_push, allowed_to_merge,
allowed_to_unprotect, and more.
This one-step method decreases the risk of a bot
changing this setting and leaving a branch unprotected.
See Documentation and Issue.
Related
There is an unstable gitlab server and I am not sure that it will be able to work in the future. Therefore, I want to make a backup copy of all the repositories (projects) that are there.
Cloning the source code will be enough, but it will be great if there is a way to save issues as well. Are there any ways to do this?
It depends on what kind of access you have, but if you don't have administrator access to do a full backup, then the best thing to do is to use a couple of API endpoints to get the information you need and go from there.
Use the Projects API to get a list of all projects accessible to you.
Note the pagination limits.
What you store depends on how you want to get the information.
Store at least the ID number of each.
Filter by membership if you only want the ones you're a member of.
Filter by min_access_level = maintainer (or higher) if you want to export whole projects.
Use the Project export API to trigger a project export for each project you're a member of, and you're a maintainer (or higher).
For all other projects where you have a lower role, or where it's public, you could still use git clone for the repositories by storing the ssh_url_to_repo or http_url_to_repo from the Projects API and running through each.
For all other parts of a project, you could store the JSON version to recreate them later if you want to go through the hassle. For example, for issues, use the Issues API.
I am using Pull Request Manager Hub from the marketplace for our azure dev ops projects/repos. id like something that has a cleaner UI. It seems too busy and like everything is a button and some of the icons don't show up completely. I don't want to complain too much but is anyone using something else that they like more? My main requirement is that I should be able to see all pull requests across repositories in the same project.
I’m the creator of Pull Request Manager Hub and new improvements (better UI, lots of new features) have been released to address some of the main complains. Also, feel free to open issues in the GitHub repo where we try to fix as soon as possible.
Thanks ;-)
My main requirement is that I should be able to see all pull requests
across repositories in the same project.
For this demand , you can use Pull Request Search extension. This extension allows pull requests to be filtered by status, creator, reviewer, title, start date, end date, and repository. You can specify different repos in the same project in the Repo drop-down list.
Another extension Pull Request Dashboard can also view pull requests across all repositories. But it has a flaw, you can only see the pull requests with active status.
https://marketplace.visualstudio.com/items?itemName=mimeo-vs-marketplace.mimeo-active-pull-requests has a plugin called 'All Active Pull Requests' (among others) is the best I have found so far.
I am currently using GitLab Community Edition 9.0.0 and want to change default branch to "develop" for every project.
I know it can be done by project settings page but since we have almost 200 projects, is there easy way to do it?
You could use the Gitlab API to:
Get a list of all the projects (see here)
Loop on that list and edit every project to set the default_branch parameter (see here)
Here's more documentation on how to use the API.
You fist need to get a user's private token. Go to http://<gitlab_domain>/profile/account to get/generate one for your currently logged in user. You may want to do that as the gitlab administrator in order to have access to and be able to modify all those projects.
Then you need to generate the proper requests (see links above and this).
I've been using git for a little while now in a new project I am working on.
I decided to use GitLab.com as I would like the opportunity to keep me repos private until I'm ready to share them (which github doesn't allow me to do).
The whole beauty of git for me is that I have a copy of the whole repo on my local machine and on the remote site.
However I make lots of comments, on my 'local' gitlab instance.
I know that I can put the wiki into source control, is it possibly to do the same thing with the comments and milestones (or in some other way share them between repositories)
I feel that this should be possible.
Maybe using an rss feed to push and pull the data to / from the various locations.
Or can I use the issues as a 'mailing list' somehow, with a 'mail into list' (however I would then need to get my local gitlab instance to mail any new issues to the remote - could probably be setup using some form of 'auto forward' filter in my mail client / gmail.
Are any of these ideas even possible ?
Is there a better solution - I'd prefer something that will integrate into my gitlab instance (local and remote), rather than needing having to use a separate interface ~ I like everything to be in a single place if possible.
Remember also I like to have access to my issues etc when offline (and then have them 'sync' when I go back online).
Thanks for any help in advance.
David
You could build a script and make use of the API to sync your issues and notes. Maybe a script that pulls all of the new issues and notes and POSTs them to the equivalent projects on GitLab.com. You could run the script manually or create a cron job to post the new items periodically.
For a product based GIT repository, wherein there are branches for maintenance, testing as well as future development, how do I control user access to these branches. By access, I mean that even though others may read from it, they should not be able to inadvertently push changes to the repo.
For example,
A - B - C - D - E - F -> master
| | |
V1 V2' exp
|
V2
"B" is the commit used for Branch with tag V1 - meant for released version of the product. Only support/maintenance engineers should have access to this.
C is used for a recently frozen pre-release product V2' and should only allow critical show-stopper bug fixes, so only certain developers and the Testing team should have access to it. when V2 is released from this branch, only Support should access it as is the case with V1.
E is used for branching off for testing a new feature for future V3 - only developers and not Support should access it.
"master" changes should only be merged on a request basis (similar to say, GitHub) by a central integration team.
How can the above be achieved with git? I recall seeing gitosis and some other external tools - are these essential for secure operation with git or are there any other best practices?
Thanks.
ADDED
Gitflow best practice branching model
The other classic way to restrict push access to a repo (or a branch or even a directory) is by using gitolite (which actually is a big evolution of gitosis).
You can define there (in the gitolite config file) any group of users or group of repos you need and associate RW access rights.
Note: August 2013:
Stash provides read-only branches,
and BitBucket should do the same soon
We've released branch restrictions which can be configured via the repository admin "Branch management" screen.
Assembla provides such a protection as well (since March 2013).
GitHub doesn't have yet this feature:
GitHub has that feature since Sept. 2015: see "How to protect “master” in github?".
Put a server side commit hook that denies commits to whatever branches you need read-only or based on who the committer is.
For merging request work flow, we use a local install of Gitorious and submit merge requests through its web interface and restrict the main-line repository to your integration team, everyone else would work from server side clones and then push merge requests back to the main-line repository.
With Gitorious you don't need the server side hooks, you just need to restrict access to the main-line repository to only the people you want to be committer. Much simpler and easier to maintain.