I am new to GitLab. I want to create a list of reviewers for my project. How do I can create it? I just want to assign a reviewer from my group to one merge-request.
TIA
There are several possibilites regarding the Merge Request Approvals documentation:
Enforcing review of all code that gets merged into a repository.
Specifying reviewers for a given proposed code change, as well as a minimum number of reviewers, through Approval rules.
Specifying categories of reviewers, such as backend, frontend, quality assurance, database, and so on, for all proposed code changes.
Designating Code Owners as eligible approvers, determined by the files changed in a merge request.
If you want to organize your developers, you can also use a group, for example.
Related
Problem
I have a gitlab with a lot of old repositories. I want to mention my gitlab as a reference on my CV but I do not want all the old repositories to appear there, just the more relevant ones.
Just making the projects private is not enough as this leaves a lot of clutter in my dashboard and it is hard to see the projects I am trying to showcase.
I do not want to delete the old projects, as I want access to them in the future, I just want to hide them from other people to see that they even exist.
What I Tried
I tried archiving the old projects but they still appear on my Projects lists, just with an archived tag.
I saw mentions of playing with the "Metrics Dashboard" under the visibility settings but this is greyed out for me + I do not think this is what I need from my understanding.
Required Result
For me to be able to choose which projects appear and do not appear in my gitlab dashboard.
Thanks in advance for any help available!
EDIT
I found out that I can star and un-star projects, and that will count as activity on the project without actually changing anything. As the dashboard displays projects by when there was last activity on them then you can actually arrange your project by staring and un-staring the projects in the reverse order you want them to appear.
This somewhat does what I want, but with an ugly work around. Also it will always display 10 projects as far as I can tell, so if I want to only showcase 6 of them the best I can do is push the 4 I don't want to the bottom, but I still can't hide them completely.
This is why I am not writing this as an answer to my question. There has to be a way to just tell a project to be hidden or arrange the projects without this ugly workaround, and if there truly by design isn't a way of doing this then it will also just be good to be officially told that.
GitLab Groups do exactly what you need. See here for more info.
You can assign each project to a different group
You can move a project from one group to another as needed
You can assign different permissions and visibility for each group
You can also create subgroups
Each group/subgroup is treated as a separate namespace, meaning you access it using a different URL
So you can define a public group called yourfullname and a public subgroup called portfolio. Move the projects you want prospective employers to view to the portfolio subgroup and make sure their visibility is also public. All other groups/subgroups should be private. Then people can access your projects by visiting the following URL:
gitlab.com/yourfullname/portfolio
You can still view all of your projects in a single dashboard if you want, or you can view all projects within a group or sub-group by navigating to the desired group URL or dashboard. In the image below, archive and development are private (see the lock icon), but portfolio is public:
We have a Gerrit with quite a huge namespace and projects environment and every project has different rights in a matter of code-review or workflow voting and submitting. I sometimes create a set of batch changes accross several projects and then I need reviewers to check and submit. Is there any way how to filter the search results to show only the project which the user searching them can review or submit? Currently, I usually send the results just based on the topic, but this approach still shows all the changes to the reviewers even if they don't have rights to review. Any ideas on how to do or workaround this?
This solution is not exactly what you search for but maybe it can help:
You can use the clause visibleto:'USER-or-GROUP' to match only changes that are visible to 'USER' or to anyone who is a member of 'GROUP'.
More info in Gerrit documentation here.
We have a CI/CD setup in Azure DevOps that gets triggered from push on master branch. Is it possible to make the approver the user that was the cause of the build trigger?
The idea behind this is that we have many developers in our team so I want the specific dev that pushed changes make the decision on whether or not they want the changes deployed, vs. a dedicated approver.
Short answer, no.
Context:
This is the opposite of a good practice, which is why there's an option to require someone else to be the approver, but not the person who made the change. You don't want the person who made a change to be the one to approve it, because that enables a single person to sneak a change through. This means that mistakes can slip through, or even intentionally malicious changes.
The best practice is to require someone other than the person who made a change to review and approve the change.
While I totally agree with #Daniel Mann on why this shouldn't be done, the way I've seen it happen is that the Team is assigned as the recipient of the approval request, and the user requesting a release or deployment should not approve it checkbox remains unchecked.
Then to avoid the inbox noise of the approval request, turn off the notification for the team about pending release approvals.
EDIT
If you must have only that one person assigned as the valid user to approve changes for deployment, you could do this too, but it wouldn't be pretty. You could have a "stage" per person. These stages would use artifact filters in the pre-deploy conditions to only send approval email to the person that stage is for.
After the approval it forwards to the actual deployment stage to do the work.
Now you need to add the username or something as the tag on the build. I'm unsure if there's a tool/task to do this as part of the build pipeline to keep it continuous, but I know you could figure out how to do it from the REST api. Perhaps you would need to create a pre-approval stage that runs a PS script to access the REST api and tag the provided build with the value of requestedBy property on the build.
Again, see how hard it is to do this? That probably means you're not following best practices. "Make the right things easy and the wrong things hard." -Unknown
Currently I have an GitHub repo that I use for collaboration. I want anyone to be able to join it.
GitHub currently requires users to first find me (there is no form to request) and ask me and then they are mailed an invitation which they then have to accept.
I'm guessing there is an app out there for this but I can't find it.
I'm looking for either an integration that takes a turns a issue comment into a team add, or form the user can request an invite from.
Forking a repo remains the official way to contribute without asking. Then the contributor can make a pull request back to the original repo.
The goal is to "manage" (through PR review) the flow of contribution.
The other alternative would be to add several people owner of an organization team: that way, you would be the only one people would have to ask in order to be collaborators.
If this is an organization that you're trying to add members to, there is already some automation around that.
JazzBand allows anyone to join the organization. Their website uses the same mechanisms as add-to-org to add people to an organization.
Looking at their source code, it appears both use the GitHub API to add members to an organization.
PUT /orgs/:org/memberships/:username
That said, if this is a personal repository, you'll instead want to follow the API to add a collaborator
PUT /repos/:owner/:repo/collaborators/:username
It's likely you could modify either of those projects to fit this need. Cheers!
background
I've been a religious user for github/zenhub for quite a while. We recently moved our repos to gitlab for many reasons, including free pipelines, security, more flexible groups etc.
Problem
Zenhub is a greasemonkey app that's added to github, one of its features is the scrumboard that's similar to gitlab's native issue board. One of the amazing things about zenhub scrumboard is that it allows you to put many repos on the same board (I recall jira had the same thing).
question
Is there a way to do this on gitlab?
Beside a third-party like kanban.leanlabs.io, recent GitLab releases do integrate a more sophisticated issue management.
See "Announcing The GitLab Issue Board " (presented here)
But it might be limited to only the current repo.
Note that with GitLab 13.6 (November 2020), this is no longer limited to a repository:
Group-level management of project integrations
In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well!
Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.
A great example of this is using our Jira integration. If you’re using Jira, it’s almost always across the whole company. Some of these companies have thousands of projects and therefore had to configure each and every one of those integrations individually.
With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
Read more in our announcement on the GitLab blog.
See Documentation and Epic.
In GitLab issues and merge requests within a group display a collection of issues and merge requests from all projects below them.
And they also have an Issue Board available, which aggregates the issues from the projects within the given group. This is currently not reflected in the documentation, and could be well worth a Pull Request in doc/user/group/index.md and doc/user/project/issue_board.md.
Using this together with group labels and milestones, which also span across all subprojects, you can create the desired board view.
I do use github/zenhub in the past. https://gitboard.co is the zenhub alternative for gitlab. Which shows all your issue and merge request in one simple dashboard across multiple projects.