This also required making a builder change.
See https://github.com/k3s-io/k3s/issues/7475 for context.
This applies to 1.26 and 1.27, it just happens that 1.27 also worked
without it
On unstable, we're now tracking
| version | EOL |
|---------|-----|
| 1.24 | 07/2023 |
| 1.25 | 10/2023 |
| 1.26 | 02/2024 |
| 1.27 | 06/2024 |
This commit adds 1.27 using the 1_26 builder introduced in the last
commit.
Notably, this commit also updates the 'update.sh' script to work for the
new setup I have here.
This is meant to make it easier to maintain multiple versions of the
package without having to copy+paste folders every time.
We can still copy+paste if the builders diverge enough to warrant it.
This version is no longer supported, as of roughly 1 week ago, according to [k8s upstream docs](https://kubernetes.io/releases/patch-releases/#non-active-branch-history).
There's additional discussion about the future of k3s versioning in #222604. This gets the simple uncontroversial change out of the way first to ensure people can't accidentally pick this unsupported version.
We dropped behind on releases for a bit due to our automatic update
script breaking.
This happened because of the traefik chart packaging changing
considerably. See the related upstream PR https://github.com/k3s-io/k3s/pull/6519
This updates our packaging to work with the new setup. Conveniently,
this also lets us drop a patch since chart packaging upstream has
simplified some too.
This updates k3s.
This one's done by hand rather than via the update bot since the
upstream repo ended up in a state where `go mod download` didn't work,
and we had `proxyVendor` set (which causes a `go mod download`).
Deleting `proxyVendor` works now though, and I didn't actually fully
understand why it was needed before, so I've removed that. Which
unblocks the update.
The actual update was done via `./update.sh` after removing
`proxyVendor` and the `k3sServerVendorSha256` variables.
This PR also reworks the packaging of k3s significantly.
Notably, it makes the following changes:
1. buildGoModule instead of buildGoPackage + mkDerivation (for the final one)
2. Merges the final two derivations (k3s user binary + wrapper script stuff) into one
3. Reduces the amount of patching & usage of upstream packaging scripts
And of course updates to 1.23
I'm not really sure yet if this is significantly better than the
previous packaging model, but it at least seems a little nicer I guess?
buildGoModule is nice, even if we have to hack around it quite a bit to
get a 'go generate' in there.