Hello, Codeberg Pages
Moving this site from Gitlab Pages to Codeberg Pages
In their own words, taken from the docs, “Codeberg is a democratic community-driven, non-profit software development platform operated by Codeberg e.V. and centered around Codeberg.org, a Gitea-based software forge.”. Essentially, it is a non-profit platform run on donations for sharing free and open source software by providing a collaborative VCS environment based on Gitea. One good day I decided to move all my open source repositories from GitLab over to Codeberg, and that includes the hosting of this very website. This is the story of this migration.
Why Codeberg pages?
Codeberg offers a Pages component where users can deploy, publish and host their own static sites, just like GitHub or GitLab pages. However, the configuration right now is a bit more barebones than in those other proprietary options, as you can’t rely on a CI system to deploy the site for you. I like that, as I feel like I’m more in control of the whole process. I can produce the static site locally and then push it to the remote host. Codeberg also supports HTTPS via certificates provided by Let’s Encrypt. The process of setting this up is totally transparent and, to be frank, surprised me for the better. In my particular case, I need the site to be available at my two domains (tonisagrista.com and sagrista.info), which adds a grain of complexity to the whole thing.
Start with the docs
As always, a very good starting point is the official documentation. In this case, a quick visit to codeberg.page provides the essential information at a glance:
Create a public repository named
pages, or create a
pagesbranch in an existing public repository.
Push your static webiste content into that repo or branch.
Done! Your repository should be accessible at
https://USER.codeberg.page/[/REPO][/@BRANCH]. However, if you want to use your own domain you need (a) a
.domainsfile with the domain name, and (b), the following DNS configuration:
@ TXT [[BRANCH.]REPO.]USER.codeberg.page
That works pretty well. In my experience, the DNS records took a while to update and the HTTPS certificate (via Let’s Encrypt) returned certificate errors for a while. After that short period, all worked just fine.
More than one domain, no redirection
However, the issue comes when trying to add two domains without redirection. You see, the
.domains file contains a domain name in each line. The first domain name is the main one, while all the others are redirected to the first. What if you do not want redirection? The solution is to deploy your site to different branches, one for each domain. This involves pushing a different
.domains file to each of the branches, and using a different
TXT record for each domain name, pointing to the relevant branch.
Again, in my case, I generate my static site using Hugo from a repository that contains the source files (which lives in the
master branch). To actually generate it, I need to invoke the CLI program
hugo. This generates the static site in a sub-directory (named
public by default), which I need to push to a different branch for each of my domains. I’m using the following branches for the listed domains:
I have written a shell script which deploys the sites according to the configuration at the top. A list of domain/branch pairs is provided, the rest is handled automatically.
Line 13 contains the list of branches. Line 15 contains the domains. These are matched by position, so take that into account.
Some parts are specific to my configuration, like the call to
minify-all on line 30. You can ignore those. As for the rest, I only need to edit the sources of my site and then run the script. The site is automatically deployed to both my domains.