How to add all users to a project, including new ones? - gitlab

I would like to setup a sandbox project in my school GitLab server (self-hosted, free), that all users, especially new ones, can use to test whatever they need.
How can I add all users to the same project?
I already read this releated question (that asks the opposite), but it only partially help; the most useful answer tells me to use the API, which is good if I want to add all current users to a project, but I also want to add new ones.
Is there a way to add a user to a project, triggered by that user being confirmed?

One builtin method would be to use system hooks. For example, you can create a hook that responds to user_create events and adds the user to the project.
Another way may be just to run a scheduled CI pipeline that scripts this or similar automation (e.g. cron job on the server or whatever).
You can use the users list API to enumerate all current users in your GitLab instance (requires admin privileges). You can also use the project membership API to enumerate all members of the project. You can compare the two results to find any users that need to be added.
Pseudocode:
project_members = get_project_members(project_id=1234) # project members API
for user in get_all_gitlab_users(): # list users API
if user not in project_members:
add_project_member(user=user, project_id=1234)

Related

What is the easiest way for users to update Discord commands?

I have a Discord bot deployed on Heroku. The deployment method is via GitHub update. I was using Node.js and Discord.js library.
When we need to add some new commands ad hoc, I need to add:
some data at Firebase Real-Time Database
command inside command/name_of_command.js
update the bot (via git push to GitHub repository)
run deploy-commands.js script so the commands are updated
This is all fast, but I wish for total independence of:
code and data
me and the users
I wish that users can add in a very easy way, new commands, and that's it. What troubles me is:
even if users can update the commands, (or update the database), someone still needs to run deploy-commands.js
if the commands can be added to the bot dynamically, either from db or from some config file, still someone would need to call some script file each time, right?
Tell me your opinion, on what would be the easiest way for users to keep adding commands without me.

How to clone all public repositories from gitlab server?

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.

GitLab change permission of protected branches

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.

Gitlab change default branch for every project

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

Jenkins user-based job security

I have just a single instance of jenkins on a local machine which we are using to build our code. We have different project teams working on different projects, and different jobs for each project.
To eliminate the possibility of someone from one team accidentally messing up another team's job, i have created multiple jenkins users.
However, all of the users that can log on still see all of the jobs. Is there a way for certain users to only see the jobs that pertain to them?
I have searched extensively for something like this but no luck. I haven't found any plugins for this. I am using matrix based security currently, and although you can change the permissions of all the users through this, you can not apply specific permissions to specific jobs. At least to my knowledge. Any ideas?
Just to clarify, I want one of the many teams to log in to their user account in jenkins, and only see their jobs. The jobs of the other teams should not be visible, only the ones that they are assigned should be visible when they log on
The closest thing i have found for this is in the Role Strategy Plugin, there is a user-based job filter
Turns out there is a feature already in jenkins for this, no plugins necessary!
In the Configure Global Security section in Manage Jenkins, click "Project-based matrix authorization strategy".
Then you can configure permissions in the job configure screen for that particular job by clicking "enable project-based security".
Now you can configure your Jenkins so that "Joe can access project A, B, and C but he can't see D".

Resources