releases

CircleCI

Giant Swarm Workload Cluster Releases

This repository contains workload cluster release notes and changelogs.

Workload cluster releases can be in different states, namely active, deprecated and wip. With pull requests merged to the master branch, workload cluster releases get automatically deployed to all Giant Swarm installations.

AWS

Azure

vSphere

VMware Cloud Director

EKS

Proxmox

AKS

PR Commands

Summarize Upstream Changes

To generate an AI-powered summary of upstream Kubernetes and Flatcar breaking changes, deprecations, and urgent upgrade notes, add a comment with:

/summarize-ai

This will:

The summary is only generated when there is a minor version change in Kubernetes or Flatcar. Patch-only upgrades are skipped.

To target a specific provider:

/summarize-ai --provider aws

Workload Cluster End-to-End Tests

To trigger the Workload Cluster End-to-End tests for each new Release added in a PR, add a comment with the following:

/run releases-test-suites

This will automatically trigger tests for all new releases detected in the PR and will run them against the appropriate standard and upgrade test suites for the provider.

If you need to run tests for a specific Release (from the PR) or a different test suite, you can do so with the two following, optional parameters:

The upgrade tests will first install a cluster using the latest previously published release and then upgrade to using the release found in the PR. If you need to override the starting Release version (to test upgrading from an earlier release) you can do so by setting the PREVIOUS_RELEASE parameter on the trigger comment (e.g. /run releases-test-suites PREVIOUS_RELEASE=28.1.0)

The workload cluster E2E tests are enforced by our PR gatekeeper to ensure they are passing before PRs are allowed to be merged.

Test coverage requirements

Which suites /run releases-test-suites picks depends on the release stage (stage/development runs standard, upgrade and upgrade-major, while the variant suites such as private, china, cilium-eni-mode, on-capa and on-capz only run at stage/freeze). To make sure a release is never merged without the variant suites having run at all, the E2E Coverage check requires the full set of suites for every new release in the PR, whatever stage the PR is currently in.

The check lists every expected suite per provider along with a ready-to-use trigger comment for the ones still outstanding. It only turns green once they have all passed, and the PR gatekeeper requires it before merge.

It also names the stage the PR is currently in, which suites a plain /run releases-test-suites covers in that stage, and the command to advance to the next one (/stage active, then /stage freeze — stages move one step at a time). Suites that the current stage does not run are marked accordingly, so a missing result is never mistaken for a problem.

Results stay valid while the release content stays the same: a suite that passed on an earlier commit still counts, and only a change to a new release’s release.yaml (a component or app bump) invalidates it. Editing a README, announcement or release.diff does not force a re-run.

If a suite genuinely cannot pass — for example because its test environment is down — it can be waived with a reason:

/waive-suite capa/china Beijing environment down, see giantswarm/roadmap#1234

A reason is required, and the waiver must come from an organisation member. Waivers are recorded in the E2E Coverage check output, apply to that one suite only, and become void as soon as a release in the PR changes.

Full details are in docs/workflows-e2e-coverage.md.

Conformance Tests

To trigger the CNCF Conformance tests for a new Release added in a PR, add a comment with something similar to the following:

/run conformance-tests PROVIDER=capa RELEASE_VERSION=29.1.0

The following parameters are required:

Please note that these tests take roughly 2 hours to run, so best to only run once all other changes are ready.

Currently the conformance tests can only run against a single Release. If you have more than one Release to test in your PR you can comment multiple times with the parameters changed, but be aware that only a single GitHub check will be added to the PR so you will need to manually confirm each has passed in Tekton.

Currently the conformance tests are not enforced by our PR gatekeeper.

This site is open source. Improve this page.