DEV Community

Cover image for Settings of my GitLab repositories πŸ”
Benjamin Rancourt
Benjamin Rancourt

Posted on • Originally published at benjaminrancourt.ca on

Settings of my GitLab repositories πŸ”

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

Capture of the Naming, topics, avatar section.

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? πŸ₯°

Header of the project.

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.

The same project, seen in a list of projects.

Visibility, project features, permissions

An example of project features disabled

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.

Much better, right?

Merge requests

Merge checks

Screenshot of the Merge checks section.

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)