kubernetes / website

Kubernetes website and documentation repo:
https://kubernetes.io
Creative Commons Attribution 4.0 International
4.6k stars 14.49k forks source link

Formalize processes for regularly upgrading website tools #37187

Open a-mccarthy opened 2 years ago

a-mccarthy commented 2 years ago

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:

a-mccarthy commented 2 years ago

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

sftim commented 2 years ago

/priority important-longterm /triage accepted

tengqm commented 2 years ago

Thanks for filing this.

a-mccarthy commented 1 year ago

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

Also included in the netlify.toml file:

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, https://github.com/kubernetes/website/issues/22229, but its not clear to me how we use Ruby. Similarly the node version was added to avoid build errors, https://github.com/kubernetes/website/pull/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 commented 1 year ago

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

sftim commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

a-mccarthy commented 1 year ago

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 commented 1 year ago

What needs to happen next on this?

sftim commented 1 year ago

/lifecycle frozen

k8s-triage-robot commented 6 months ago

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

You can:

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

/remove-triage accepted

stmcginnis commented 6 months ago

/triage accepted