Whenever I create a new GitLab repository , I mostly keep configuring them with the same settings , as I generally use the same GitLab features in my projects.
Why should you take 5 minutes to review your repository default settings? Because GitLab offers a lot of features, but there's a good chance you won't be using them all. Moreover, by examining them, you will also know better the possibilities offered by GitLab. 😀
So, in this post, I want to show you the changes I usually make to my GitLab repositories. This may prompt you to take a closer look at your settings. 😉
General
Naming, topics, avatar
Perhaps the most important settings in your repository are in this view. I always try to describe the project, so my colleagues (and I) can quickly know the purpose of the repository without looking at the README.md (if available) or the code.
I also try to find a suitable avatar for my projects, to make them more personal. It is a nice touch, don't you think? 🥰
I can also associate the image with the project, so that I can find it more quickly when I search for it in a project list.
Visibility, project features, permissions
Yeah, GitLab offers a lot of features, but unless you use only GitLab, chances are you won't be using all of them. By turning them off, you will keep your menu less cluttered and you will be able to find quicker the option menu you want faster. (run)
So I usually disable the following features:
- Container registry: unless you plan to publish a private Docker image, you can definitely get rid of this feature.
- Git Large File Storage (LFS): since I don't usually store large files, this feature is usually disabled.
- Packages: if you do not plan to publish to a private registry (npm, Maven or Composer by example), you can also deactivate it.
- Analytics : as we primarily use JIRA to track of our bugs and feature requests, the analytics view does not provide us useful analytics...
- Security & Compliance : unfortunately, the security features come with a paid tier, so this view is mostly about promoting an upgrade to a better plan.
- Wiki : the majority of my documentation is located directly inside Markdown files.
- Snippets: personally, I don't maintain a list of codes that I want to keep handy or share with others. And I have not see a single person use this functionality yet, so...
- Pages: as most of my sites are currently deployed on Netlify, I am not using the GitLab Pages feature.
- Operations : I am not sure, but this feature seems to be related to Kubernetes and since I have not explored it yet, the menu link points to empty views, so I turn it off without further question.
Merge requests
Merge checks
For a Merge Request, I think it is a bit rude to merge without responding the to a colleague's comments, so I am enforcing the need to have an agreement directly in GitLab with the option All discussions must be resolved.
Also, if a pipeline is configured, I make sure to check the Pipelines must succeed option, because that means if you have a pipeline, you usually want it to pass your tests, right? 🙃
Service Desk
There is another feature that, for some reason, stands alone: the Service Desk. I have never use it, so I would probably need to watch a little demo to see if this is a feature I would like. In the meantime, I deactivate it! 😈
CI/CD
General pipelines
The last view I configure is no less essential if your are using CI/CD. There are two values that I lower:
-
Git shallow clone : the number of changes to fetch when cloning the repository. I set it to
1, because it says that a lower value can speed up the execution of the pipeline. 🚀 - Timeout : unless your pipeline takes a lot of time, you should really change the default value of one hour (😱) to something more appropriate, like 15 minutes or 30 minutes. If you can cut it down to just 5 minutes, that's event better!
Conclusion
I hope you learned some new GitLab settings today! And you, what are the settings that you modify? 😇
Top comments (0)