Wen Ping

Posted on Oct 29 Originally published at anguskit.com

Self-hosted GitLab uses too much memory: keep repositories and pull requests

#git #angusgit #gitlab

This article explains how to put repositories and review on a lighter AngusGit when an intranet GitLab is using a large amount of memory and the team only uses those parts. After reading it, you can create repositories under a team, move them together with their history, set the merge method and branch protection, leave builds on Jenkins, and leave artifacts in an artifact repository.

Sign in to AngusGit first. To move one repository, open Settings → Team, click New Team, and set Team Slug to the GitLab group’s English name. In the sidebar, open Repositories → New repository, set the owner to that team, and leave Add a README file, Add .gitignore, and Choose a license unchecked. If any box is checked, the push is rejected because the histories do not match. If this machine has no public key, run ssh-keygen -t ed25519 -C "you@example.com" and register the line from cat ~/.ssh/id_ed25519.pub under Settings → Profile, on the SSH Keys tab. Then run the commands below. Replace the addresses. If the main branch is named master, run git branch -m master main inside the bare repository first.

git clone --bare https://gitlab.example.com/group/project.git
cd project.git
git push ssh://git@git.example.com:2222/team/repo.git --all
git push ssh://git@git.example.com:2222/team/repo.git --tags

The username is git, and the port is 2222. For HTTPS, open the Access Tokens tab and generate a token with git:write and repository permission WRITE. The username is your login name, and the password is the token. Check with the command below. No unexpected output means the two sides match.

diff \
  <(git ls-remote --heads --tags https://gitlab.example.com/group/project.git | sort) \
  <(git ls-remote --heads --tags ssh://git@git.example.com:2222/team/repo.git | sort)

When there are many repositories, write one GitLab path and one “team/repository name” per line in repos.txt, and repeat the same clone and push for each line. Push one repository by hand first, save the token in the system credential prompt, then run the loop. When master was renamed to main, that one name difference is expected.

A pull request is what GitLab calls a merge request. It is the same action as the Pull Requests label on AngusGit: ask to merge one branch into another after someone reviews the change.

GitLab uses memory because its all-in-one package includes a database, a cache, background jobs, built-in CI, a container image registry, monitoring, and the rest of that set. Even if you only host code, those processes keep running. If your pipelines already run on Jenkins and your artifacts already have their own repository, AngusGit starting at 2 CPU cores and 4 GB is enough for repositories, pull requests, and code review.

1. First, confirm the team really uses only these three

Before you start, spend ten minutes confirming which GitLab features are actually in use. Ask through this table:

Feature	In use?	Where it goes after the split
Repository hosting, push and pull	Almost certainly	AngusGit
Merge requests and review on the web	Almost certainly	AngusGit
Issues and milestones	Depends on the team	AngusGit has them, so they can move too
GitLab CI	Maybe	If it already runs on Jenkins, keep Jenkins
Container image registry and package registry	Maybe	An artifact repository, for example AngusRepo
Git LFS	A few teams	AngusGit does not support it. Leave those repositories where they are for now

Git LFS (Git Large File Storage) stores large files outside the repository. If the answers for GitLab CI and Git LFS are both "not in use", the split goes smoothly. If the team depends heavily on GitLab CI, read the selection article linked at the end and decide how pipelines will be handled.

2. First piece: repositories

Every repository on AngusGit hangs under a team. The address looks like ssh://git@git.example.com:2222/team/repo.git. Moving a repository has three steps: create the team, move the repository, then have developers change the remote URL.

Create teams that match today's groups

Under Settings → Team, click New Team. One team matches one GitLab group. Team Slug appears in the repository URL. Reuse the GitLab group's English name so the new remote is easy to remember.

Move the repository together with its history

Create an empty repository with the same name on AngusGit. git clone --bare makes a full copy from GitLab. A bare repository stores only Git data and has no working files you can edit. Then git push --all and git push --tags send it to AngusGit. Commit history, every branch, and every tag come with it.

Have developers change the remote URL

Each person runs git remote set-url origin in the local repository and points it at the new URL. For SSH, register the public key under Settings → Profile, on the SSH Keys tab. The page title there is My Profile. For HTTPS, the password field is a token from the Access Tokens tab.

The commands, the credentials, and the comparison are at the start of this article. Push one repository by hand until it succeeds, then repeat the same clone and push for every line in repos.txt.

3. Second piece: merge requests

On AngusGit, a merge request is a Pull Request. You use it the same way as a GitLab merge request: open it from a feature branch and merge it into main.

Decide the merge method before people start. Open the repository's Settings → Pull Requests. Three switches are there: Allow merge commits, Allow squash merging, and Allow rebase merging. Turn on only the one the team agreed on. The merge box then offers only that method, so each person does not pick a personal habit. If you have not chosen yet: turn on Allow merge commits when you want to keep every commit, and Allow squash merging when one pull request should leave a single commit on main. The merge-methods article linked at the end compares the three.

4. Third piece: human review

Review happens under Review in the sidebar. The reviewer opens a pull request that is Pending, reads each file under Files changed, leaves a comment on a line that needs discussion, and clicks Submit review. The choices are Approve, Request changes, and Comment.

Take the still-open xlliu/test-cicd-example #1. The title is "SC-02/SC-04 PR trigger verification", and the state is Pending. The left side is the file tree. Neither file is marked as viewed yet. The right side shows apps/service-a/src/index.js, with two added lines and no line comment yet. Submit review at the top right opens a dialog. The dialog title is Submit Review. The text says "Choose your review decision and add comments". Under that are Approve, Request changes, and Comment. The review is submitted when you pick a decision and click Submit review in the dialog. Opening the dialog and stopping there leaves the state Pending.

Up to this point, whether a reviewer approves is still a habit. To make review a rule people have to follow, turn on branch protection. That is a rule on a branch: no direct push, and the merge has to meet conditions first.

Protect the main branch

Open the repository's Settings → Branch Protection and add a rule for main. Turn on Require pull request reviews, set Required approving review count to 1, and turn on Include administrators. After you save, a direct push to main is rejected. A change goes in through a pull request, after it has an approval.

Name reviewers by directory (optional)

When different directories belong to different people, add a CODEOWNERS file to the repository and list the owner of each directory. CODEOWNERS is that owner file. When a pull request is created, the matching people are added as reviewers.

After that, the daily flow is fixed: open a branch, push, open a pull request, the reviewer approves, then merge. The branch-protection article and the CODEOWNERS article linked at the end cover each setting.

5. Who takes the features you leave out

Everything besides repositories, pull requests, and review stays with the system that already specializes in it:

Feature	Where it lives today	What to do after the split
Build and test	Jenkins	Keep Jenkins. The trigger is described after the table
Images and packages	An artifact repository	Keep them in an artifact repository, for example AngusRepo
Large files	Git LFS / storage	AngusGit does not support Git LFS. Put large files in an artifact repository or in Release attachments
Single sign-on	A user center	Users and sign-in are managed by GM. Configure LDAP on GM Enterprise

Watch the trigger on the build row. A webhook is a notice sent to an outside system when something in the repository changes. AngusGit's push webhook is sent on git push. After a pull request is merged in the browser, have Jenkins use Poll SCM (it checks the branch on a timer for new commits) to notice the new code.

After the split, each system owns one job. When something breaks, it is easier to see which side it is on.

Common questions

What happens to the old GitLab after the split?

Do not delete it yet. Make GitLab read-only and keep it for a while, so you can look up old merge requests and discussions. Archive it after you confirm nothing was missed. How to dual-run during the move (both platforms stay up for a while, and only one of them accepts writes), and how to roll back, is in the migration checklist linked at the end.

What if we want built-in pipelines later?

AngusGit Team and Enterprise include built-in pipelines. Switch to that install package. Existing repositories and pull requests stay as they are.

What if Community does not cover the headcount?

Community allows at most 10 users. Above that, switch to Team or Enterprise. Repositories, pull requests, and review work the same way.

Summary

A self-hosted GitLab uses a lot of memory because a whole set of components is running, while the team uses three of the things inside it. Move repositories, pull requests, and human review to AngusGit. Create repositories under teams and bring the history with them. Set one merge method under Settings → Pull Requests. Review under Review, then make it a rule with branch protection and CODEOWNERS. Leave builds on Jenkins, and put images and packages in an artifact repository. When you want built-in pipelines later, switch to Team or Enterprise.

Conclusion: When you keep repositories, pull requests, and code review, AngusGit starting at 2 CPU cores and 4 GB, plus GM, can replace a heavy GitLab. Leave builds on Jenkins and artifacts in an artifact repository.

DEV Community