Skip to content
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

Open
codyro opened this issue Dec 12, 2024 · 7 comments
Open

Update Hugo to latest version #712

codyro opened this issue Dec 12, 2024 · 7 comments
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@codyro
Copy link
Member

codyro commented Dec 12, 2024

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:
#709 (comment)

@codyro codyro added enhancement New feature or request good first issue Good for newcomers labels Dec 12, 2024
@alaurie
Copy link

alaurie commented Dec 19, 2024

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

image

@codyro codyro self-assigned this Dec 19, 2024
@codyro
Copy link
Member Author

codyro commented Dec 19, 2024

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

image

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?

@bennyvasquez
Copy link
Member

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.

@alaurie
Copy link

alaurie commented Jan 13, 2025

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.

@codyro
Copy link
Member Author

codyro commented Jan 14, 2025

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.

@bennyvasquez
Copy link
Member

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.

@codyro
Copy link
Member Author

codyro commented Jan 14, 2025

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants