As someone who cares about FOSS, I'm always happy to move to a FOSS alternative when one shows up, provided there aren't any big drawbacks.
Back when I was in University and starting to learn the ways of Git, I only knew about two Git hosting options: GitHub, the mainstream but proprietary, and GitLab, the less known but more open alternative. Between the two, GitLab was the obvious choice for my personal repositories, including this blog.
A few months ago I learned about Codeberg. Codeberg provides a hosted instance of Gitea, which is a Git forge that is entirely FOSS. On top of that, Codeberg is backed by a non-profit, which makes it clear that it is community-focused. As far as I'm concerned, it doesn't get better than this, so I was eager to move all my repositories to Codeberg.
Most of my repositories are really just archives: I'm the only one pushing code to them, and as long as the commit history is available, there's no other feature they require. So the migration was pretty straight-forward. The only exception is the blog repository.
The one big missing feature in Codeberg which I relied on in GitLab for my blog is the CI.
My current setup for the blog in GitLab was to have a repository with the CI configured so that whenever I pushed new changes, the CI would run pelican to generate the static pages for the website and serve them.
On Codeberg, since there's no CI, whatever files are present in the special
pages repository are directly served. This approach required me to set up
two repositories: one for the source files, the blog repository, and another
for the generated output to be served, the pages repository.
Note: It's also possible to use a pages branch in the same repository to
serve the files, but the separate repository approach seemed neater to me.
But of course I didn't want to manage the extra pages repository, since that
would be annoying and quickly make me miss GitLab's CI. So I added a new make
deploy target in the Makefile to automate the process of deploying the site to
the pages repo. It can be seen in this commit.
What make deploy does is:
make trans_deploy)make publish)pages repositorySince the output files generated from pelican need to be commited and pushed to
the pages repo, the local output directory inside the blog directory now
needs to be a git repository. To acommodate for that, the OUTPUT_RETENTION
variable needed updating so that pelican doesn't
delete the .git folder every time it runs.
I subsequently improved the commit messages for the pages repo through
this commit, by formatting them with both the commit hash and description,
in the same format that is used for Fixes: tags in the Linux kernel.
This allows me not only to correlate any commit in the pages repo to the
corresponding commit in the blog repo, but also easily tell from a glance
what the latest changes were about.
I also added a .domains file to the retention since it is required by
Codeberg for using a custom domain.
At first the need to version output files with Git put me off, but the fact that it's in a separate repository and it's easy to correlate the commits to the source ones made it a non-issue for me.
I did notice a couple advantages on the pages repo approach over CI. First,
I don't need to think about the image and package versions I'm using for the CI
because there's no CI. As long as my local system is able to generate the blog,
I'm good (and I already needed to have a working local setup to test changes
before pushing anyway). Second, as soon as I make deploy, the new changes
are live, while GitLab's CI would have taken a minute or so to update.
So it took some little changes to have a good blog setup on Codeberg but I'm happy with the move. Codeberg feels like a nice new home and I'll be sure to take good care of it đŸ™‚.