fix(blog): rephrase a few sentences in a previous article
All checks were successful
/ all (push) Successful in 36s

This commit is contained in:
Julien Dessaux 2025-06-11 14:08:12 +02:00
parent 8354360aaf
commit 202178bd4b
Signed by: adyxax
GPG key ID: F92E51B86E07177E

View file

@ -9,18 +9,17 @@ tags:
## Introduction
I just fixed an RSS feed generation that first started a month ago after
I just fixed an issue with RSS feed generation that began a month ago after
migrating the CI job that builds my blog from a git hook in Gitolite to a
workflow in Forgejo actions.
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.
I only realized this issue after not seeing yesterday's article appear in my
[miniflux](https://miniflux.app/). I was puzzled when I noticed that the [XML
index file](https://www.adyxax.org/index.xml) did not contain any articles on
the hosting server. I immediately checked the Forgejo Actions workflow logs, but
there were no errors or warnings. Whatever was failing just failed silently.
## Solving the issue
@ -34,19 +33,20 @@ 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.
and pushed a commit so that I could inspect a CI run in progress. I managed to
SSH on the runner, navigate 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.
I therefore examined the workflow closely 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.
Therefore 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.
With this new 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
@ -56,5 +56,6 @@ 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.
It was frustrating to encounter a silent failure in Hugo over something
seemingly trivial. Despite the silent failure, I was relieved my past
experiences made it straightforward to resolve.