AlmaLinux
Update Hugo to latest version
We pin Hugo to 0.98.0, while the latest version is 0.139.4. There have been a ton of QoL improvements, which we could and should leverage.
All that needs to be done for this is to verify that the site builds and runs cleanly (look for Hugo warnings and errors). If it doesn't, we'll want to fix whatever is wrong (EX, deprecated functions, etc.).
After that someone from the Infrastructure will verify everything and update the CloudFlare Pages version (HUGO_VERSION environmental).
Further context: https://github.com/AlmaLinux/almalinux.org/pull/709#discussion_r1878503549
I think the current build process is pulling the latest version regardless of any pinning done.
https://github.com/AlmaLinux/almalinux.org/actions/runs/12401185107/job/34620009233
I think the current build process is pulling the latest version regardless of any pinning done.
https://github.com/AlmaLinux/almalinux.org/actions/runs/12401185107/job/34620009233
Whoopsie doodle. You're right! I forgot we changed how we published the website a while ago, making that environmental variable unused.
For some context, we use Cloudflare Pages to serve the website. Previously, we had the website cloned and built on their end (https://developers.cloudflare.com/pages/framework-guides/deploy-a-hugo-site/#use-a-specific-or-newer-hugo-version). However, at some point, we needed to work around some gotcha and ended up using a GitHub action to build the website via a GH runner and then upload it to Cloudflare Pages. It looks like we never pinned a version in that action: https://github.com/AlmaLinux/almalinux.org/blob/master/.github/workflows/publish.yml#L21-L24
@jonathanspw We should consider pinning to a version to avoid accidentally pushing a broken version of the site unexpectedly. Thoughts?
with my marketing SIG hat on: Unless it's likely to cause problems from a wider perspective, I think it's worthwhile to try to keep this at the latest version without pinning. It's been this way for a while, and (unless this situation was a fluke) when the site is broken the build process already fails, so we aren't going to publish a broken version of the website.
I can see a possibility of other kinds of breakage that might pop up, so it might be worth it, but I'm worried that it'll get forgotten and not upgraded on a regular basis, so I'd like to request that we don't pin it unless we absolutely have to.
I'd agree to leave it on the latest. Hugo is fairly mature now and are unlikely to start adding in breaking changes outside of major version changes. Plus if there is a breakage the build fails and doesn't get pushed as @bennyvasquez said.
We have run into issues here and with $DAYJOB where Hugo will deprecate functions and produce a warning or unexpected functionality (cc: @mattrandomnumber), but no error until the function is deprecated, at which point the website fails to build until all things are fixed. It is a massive pain (thanks for fixing ours Matt ♥️).
While this won't produce a broken production website, it can cause a bit of a pain in the ass if we need to publish something ASAP/at a specific time to only see the CI/CD fail.
I am pro pinning. Ultimately it will be myself or Jonathan fixing any fires that crop up. Unless there is something compelling, I'm going to proceed to pin to the latest major stable for the time being to ensure our lives are easier.
Edit: We are an EL distro we like stability.
Sounds good. It was me that fixed it last time, but I understand what you're saying. :)
Can we also put in place a scheduled plan to keep it upgraded regularly as well? Even if it's just an automatically created issue here to remind us to take care of it. If we hadn't changed unintentionally, we'd still be running a very out of date version of hugo at this point.
Yes, let me see if there is a good option to handle something like that (recurring tasks).
Since I have the same "problem" at $dayjob it shouldn't be a problem to keep on top of this.
I will earmark this issue for today and figure out a workflow that makes sense (I hope).
To add to this, I just added specific version pinning in the devcontainer support PR as well to aid this. https://github.com/AlmaLinux/almalinux.org/pull/709
We should see what's left to get that merged in. I think it's primarily documentation?
I added some further details to the readme.md in the devcontainer dir, what sort of detail do we need?
Also, what version of Hugo are we pinning? I'll set that as the default in the devcontainer.json
I think this issue can be closed, since it's already updated. I did just submitted a PR to pin the hugo version. :D https://github.com/AlmaLinux/almalinux.org/pull/741
Ok, I've set the devcontainer default version to 0.141.0 as per you pinning PR.