It’s no secret that GitLab is a beast of an application. As self-hosted git servers go, it’s easily the most powerful and feature complete. But that weight comes at a cost: resource usage. GitLab is no slouch, easily consuming upwards of 6GB of RAM by default without doing anything, and…
As a developer I do basically everything in
git and for fun I run my own
git server on my home server. I’ve swapped around quite a lot between GitLab and Gitea, but finally settled on GitLab. It’s a bit heavy, but the deep CI integration is really nice.
Since posting, I've actually migrated back to Gitea.
After setting up GitLab, I imported the repositories from my previous Gitea server, and some other really old projects from GitHub. GitLab supports a variety of import sources, and will even auto-discover repositories from both Gitea and GitHub (although the UI really hangs with the nearly 700 GitHub repositories I have access to).
However, once you go back to the “Explore” page, there’s a problem. By default, repositories are listed by their “Last updated” date, which according to GitLab is right now, at the import date, rather than when the source repository was last updated. This means not only are the imported repositories not in the correct order, but over time they mix in with the rest of my repositories.
The exact definition of “Last updated” is quite difficult to establish retroactively - it could be anything: commits, PR creation / merges, branch pushes. Because most of the repositories were only contributed to by me, there weren’t really any outstanding PRs or other activity, so the latest commit on
master was close enough for me.
My original plan was to write a nice and generic program (in Rust, of course) to talk to GitLab’s API, scrape the repositories and commit dates, filter them based on whether they were imported, and then manually talk to GitLab’s PostgreSQL to update the relevant database rows (there’s no web API for this, unsurprisingly enough). I started writing this tool, and quickly realized I was going to run it exactly once in bulk, and then every other time would only need a handful of repositories fixing. For all the time it’d take to develop something, the return on investment just wasn’t worth it.
Instead, it turns out that it’s incredibly simple to do with just a few lines of bash. That way I’d be able to fix things quicker, and stop having to look at the abomination every time I loaded up GitLab.
The script itself is very simple, it takes the GitLab id for a “project” (what GitLab calls the whole repository) and the date to set. Much like my original plan, it still updates the date using SQL directly, which on the 1 hand means it’s incredibly fast, but makes it a bit of a hack. My intention was to compromise and just use the date of the latest commit, but GitLab doesn’t store the commits in the database, meaning doing this all as a single query isn’t an option.
Whilst GitLab does show the commit date in the UI, it’s in a tooltip, making it difficult to copy. However, GitLab does give you the ability to download an email patch for a commit, which do contain the date as a standard format. Postgres, in its infinite power, accepts this date format as a standard, making using these dates even easier.
GitLab stores the updated date in a few columns, and reads different ones for different parts of the UI. From lots of trial and error, I’ve narrowed down the important ones to 3 columns:
updated_at. Setting these to the relevant date updates the UI in all the right places.
The script itself lives, rather aptly, on my GitLab server.
Armed with a handy script, it’s very simple to update a repository to the right date:
- Find the project
- Copy its id
- Open its latest commit, click “Email Patch” and copy the date from the resulting commit
- Feed both bits of data as arguments to the script
What’s less simple, and much more annoying, is I now have to go through all the repositories which need updating - it’s pretty monotonous work. 50 odd repositories, and that short loop takes quite a while. 10 minutes here and there, and it only took a day or so to clean them all up.
Finally, my repositories are in the right order and I no longer cringe at the sight.
Share this page
View all →
My website is a very important project to me. I’ve written a lot of content over the years, useful both to me and other internet folks. Currently, my website is a static site, powered by Hugo. Because it’s static, the content is served insanely quickly and handles any insane load…
Last year, I switched all of my hosting from arbitrarily installed packages to Docker. This made installing and configuring incredibly simple, but updating a little less defined. Whilst Docker itself is updated through the system package manager (probably), the containers themselves aren’t. Docker container versions are known as “tags”, and…