-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Hugo to latest version #712
Comments
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). |
We pin Hugo to
0.98.0
, while the latest version is0.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:
#709 (comment)
The text was updated successfully, but these errors were encountered: