Formalize processes for regularly upgrading website tools

[a-mccarthy]

This is a Feature Request

Currently there isn't a process or automation that covers upgrading the tools we use for the kubernetes.io website. Specifically Hugo and our theme Docsy.

What would you like to be added

We should determine a list of tools we need to keep updated, and then create a way to trigger updating the tools at an interval that makes sense for the project and maintainer bandwidth. Either by some automation or manually upgrading the tools

We should also make sure we have tool upgrade processes documented, especially any differences with the tools upgrade docs. (these could already exist, but i'm not sure where they are located so i included it here :) )

Why is this needed

Previously these kinds of updates were triggered by bugs in the tools. Ideally, we'd also have a way to upgrade when we want to to access new features or improvements.

Comments
Some related links:

• Slack thread about this topic: https://kubernetes.slack.com/archives/C1J0BPD2M/p1663961513084469
• Write up on upgrading hugo from the last time we upgraded: updating theme submodule #23434

[a-mccarthy]

cc: @tengqm @jimangel following up on the slack thread, i created this issue to discuss creating a website tools upgrade process.

[sftim]

/priority important-longterm
/triage accepted

[tengqm]

Thanks for filing this.

[a-mccarthy]

Heres a list of tools i found that should be things we should track to update regularly.

• Hugo
  • Kubernetes/website version 0.101.0
  • Hugo latest versions:
• Docsy
  • Kubernetes website version 0.2.0
  • Docsy latest version 0.6.0

Also included in the netlify.toml file:

• NODE_VERSION = "10.20.0"
• RUBY_VERSION = "3.0.1"

Based on looking at the history of the netlify.toml file, we update the Hugo version about 2 times a year.

Based on the Docsy theme folder history, we have updated Docsy about 3 times a year, but this year have only updated it once in April.

For both Hugo and Docsy, this feels like a good cadence, to try and update them about 2 times a year and in the event of a security update.

We added the Ruby version to avoid netilfy builds slow-downs, #22229, but its not clear to me how we use Ruby. Similarly the node version was added to avoid build errors, #20963, but it's not clear to me why we need it. Based on looking at the file history, we have update the ruby version once since it was added in 2020, and we have never updated the node version since it was added in 2020. @sftim or @tengqm can you shed some like as to why we need Ruby or Node, and how frequently we should be updating them?

[tengqm]

TBH, I have no idea why we need NodeJS or Ruby.

[sftim]

We could allow Netlify to use whatever version of Ruby and NodeJS it wants to provide.

https://www.docsy.dev/docs/get-started/docsy-as-module/installation-prerequisites/#installupgrade-nodejs explains that Node.js is required by Hugo (as a prerequisite for Docsy to work properly).

I don't think Ruby gets used anywhere.

[a-mccarthy]

We could allow Netlify to use whatever version of Ruby and NodeJS it wants to provide.

@sftim or @tengqm can you share some tips or ideas on how to test if we need to explicitly have NodeJS or Ruby in the build anymore?

[tengqm]

Maybe we can start by comment out the RUBY_VERSION="3.0.1" line in netlify.toml and see if that works?

[a-mccarthy]

I created a PR with the Ruby version commented out, #39114 . The build appeared to be fine, and used the default ruby version 2.7.0.

I found a list of the default things installed in our build image, https://docs.netlify.com/configure-builds/available-software-at-build-time/#app The defaults are an older version of Ruby, 2.7.0, and newer version of node.js, 16.

[sftim]

What needs to happen next on this?

[sftim]

/lifecycle frozen

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[stmcginnis]

/triage accepted