Use release and PR check jobs on kong-2.x branch

rainest commented 9 months ago

What this PR does / why we need it:

Add an additional kong-2.x branch to the PR and push jobs that test PRs to release branches and create releases from release branches.

The kong-2.x branch does not yet exist. We want to cut it from main after main includes this PR.

Special notes for your reviewer:

From testing in https://github.com/rainest/charts-citest:

Although we can set up a second job to use CR_MAKE_RELEASE_LATEST: false on 2.x, this doesn't seem to have much use, as it only affects the Github release info AFAICT. This is already kinda iffy here because releases already mix ingress and kong charts.
chart-releaser appears fine creating releases on whatever branch. I was not able to find recommended workflows for maintaining multiple release streams.
helm install will choose the latest non-prelease tag available when not given a specific version. We can release RC branches of 3.x without affecting installs/upgrades that don't specifically choose it, but once we release a final version, it will become the default for anyone that runs helm repo update after.
helm install --version does support partial semvers. You can use --version 2 or --version 2.31. However, I don't know that we'd have any good way of forcing users to look at 3.x upgrade information due to the way values.yaml defaults work. We could do something stupid like requiring a use3x key that defaults to false.

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] PR is based off the current tip of the main branch.
[x] Changes are documented under the "Unreleased" header in CHANGELOG.md
[x] New or modified sections of values.yaml are documented in the README.md
[x] Commits follow the Kong commit message guidelines

tao12345666333 commented 9 months ago

chart-releaser appears fine creating releases on whatever branch. I was not able to find recommended workflows for maintaining multiple release streams.

We can use different branches for the release, and I believe it would be beneficial to document the process for clarity.

helm install will choose the latest non-prelease tag available when not given a specific version. We can release RC branches of 3.x without affecting installs/upgrades that don't specifically choose it, but once we release a final version, it will become the default for anyone that runs helm repo update after.

Yes, the user needs to specify the '--devel' flag to install prerelease charts.

helm install --version does support partial semvers. You can use --version 2 or --version 2.31. However, I don't know that we'd have any good way of forcing users to look at 3.x upgrade information due to the way values.yaml defaults work. We could do something stupid like requiring a use3x key that defaults to false.

Apart from notifications or adding some additional logic, we don't have any effective way to let users know that they need to refer to the upgrade documentation for v3.x.

Alternatively, we could try adding some content to the NOTES section of v2.x.

czeslavo commented 9 months ago

Suggestion: could we use a branch naming pattern similar to what we've got in KIC (i.e. release/<chart>-<major>.x)?

rainest commented 9 months ago

Suggestion: could we use a branch naming pattern similar to what we've got in KIC (i.e. release/-.x)?

I mean we used to just use x.y.z branches, which is what I was looking at :facepalm:

Kong / charts