diff --git a/content/blog/ansible/forgejo-runner.md b/content/blog/ansible/forgejo-runner.md index f884dd8..0f082a6 100644 --- a/content/blog/ansible/forgejo-runner.md +++ b/content/blog/ansible/forgejo-runner.md @@ -1,16 +1,16 @@ --- -title: 'Deploying a forgejo runner with ansible' +title: 'Deploying a Forgejo runner with ansible' description: 'Some ansible code and a golden rule' date: '2025-04-08' tags: - 'ansible' -- 'forgejo' +- 'Forgejo' --- ## Introduction -After [migrating my git.adyxax.org to forgejo]({{< ref "forgejo.md" >}}) a few -weeks back, I started experimenting with their CI offering: forgejo actions. It +After [migrating my git.adyxax.org to Forgejo]({{< ref "forgejo.md" >}}) a few +weeks back, I started experimenting with their CI offering: Forgejo Actions. It is mostly a clone of GitHub actions, which means it is a mixed bag. I am still relying on [eventline](https://www.exograd.com/products/eventline) @@ -19,9 +19,9 @@ integration for some simple and non consequential CI jobs. ## The good and the bad -The good part is obviously the tight integration with forgejo's UI. Forgejo (or -gitea which forgejo forked from) developers also made the great decision of -adding runners dedicated to individual users, which allows me to open my forgejo +The good part is obviously the tight integration with Forgejo's UI. Forgejo (or +gitea which Forgejo forked from) developers also made the great decision of +adding runners dedicated to individual users, which allows me to open my Forgejo instance to other people without offering them access to a runner. The bad part all has to do with trying to be a GitHub actions clone: @@ -46,7 +46,7 @@ workflows. ## Making do without the runner containers -I greatly dislike the default forgejo runner containers: They package everything +I greatly dislike the default Forgejo runner containers: They package everything and the kitchen sink, which is necessary given how clunky the whole nodejs ecosystem is (which the actions rely on). @@ -55,7 +55,7 @@ warn about its dangers and I caution you too if you plan to follow in my footsteps: You need to manage the proper isolation yourself and take care of not making a mess of the host operating system! -Managing the proper isolation is not hard: instead of letting forgejo runner +Managing the proper isolation is not hard: instead of letting Forgejo runner spawn its own containers, I myself run it constrained inside either a container or a jail. @@ -68,7 +68,7 @@ with some discipline and experience I make it work. ### Tasks -Here is an example `tasks.yaml` that deploys the forgejo runner on a Debian +Here is an example `tasks.yaml` that deploys the Forgejo runner on a Debian system. It does not configure the runner itself, that I do manually once after the first deployment. diff --git a/content/blog/hugo/rss-git-and-ci.md b/content/blog/hugo/rss-git-and-ci.md new file mode 100644 index 0000000..fd02460 --- /dev/null +++ b/content/blog/hugo/rss-git-and-ci.md @@ -0,0 +1,60 @@ +--- +title: Hugo RSS feed generation issue when running in CI +description: Normal services resume after disruption +date: 2025-04-28 +tags: +- Forgejo +- Hugo +--- + +## Introduction + +I just fixed an RSS feed generation that first started a month ago after +migrating the CI job that builds my blog from a git hook in Gitolite to a +workflow in Forgejo actions. + +## The issue + +I only realized this issue after not seeing yesterday's article pop in my +[miniflux](https://miniflux.app/). It puzzled me when I realized that the [XML +index file](https://www.adyxax.org/index.xml) was empty of any articles on the +hosting server. I immediately checked the Forgejo actions workflow logs, but +they did not show any error nor warning. Whatever was failing just failed +silently. + +## Solving the issue + +I worked around the issue quickly by building the website locally on my +workstation and seeing the XML index file properly populated. I redeployed this +version of the website and refreshed my miniflux feed: it worked. + +I first theorized that I might be missing a build dependency on my Forgejo +runners. It was disproved when connecting over SSH to the runner that ran the +last build: cloning and building the website there produced a valid XML index +file once again. + +I then added a `sleep` statement before the deployment step in the workflow file +and pushed a commit so that I could inspect a CI run in progress. I manged to +SSH on the runner, find my way to the temporary build directory and reproduce +the issue there: whatever was happening was not intermittent. + +I therefore squinted my eyes a bit at the workflow and saw the +`actions/checkout` step that innocuously starts all GitHub or Forgejo actions +workflow. Having been bitten by this in the past, I knew it performed a shallow +git clone by default so I followed my instinct to try a deep clone instead: this +fixed the issue. + +With this information, I checked Hugo's documentation and figured I had to set +`enableGitInfo = false` in my `config.toml` file. When enabled, Hugo uses git to +figure out the last modification date of a file and this breaks the RSS feeds. + +Though I did not use git information anywhere in my templates, this still +affected the logic that filters which articles show up in the feed. This +particular configuration flag was a remnant from before [I wrote my own Hugo +theme]({{< ref "ditching-the-heavy-hugo-theme.md" >}}): The theme I used once +upon a time required this flag. + +## Conclusion + +I was disappointed that Hugo could fail silently on such trivial thing, but alas +it was easy to solve.