This page documents the maintenance of Submariner’s CI/CD for developers.
The versions of Kubernetes tested in Submariner’s CI need to be updated for new Kubernetes releases.
Submariner’s policy is to support all versions upstream-Kubernetes supports and no EOL versions.
The versions that should be used in CI are described below.
|Most CI||Latest||CI should run against the latest Kubernetes version by default.|
|Basic Kubernetes Support||All non-latest supported versions||One defaults-only E2E for each non-latest supported Kubernetes version.|
|Full Kubernetes Support||All non-latest supported versions||Workflow to run all CI for all of the currently-supported, non-latest Kubernetes versions. Run periodically, on releases, or manually by adding the
|Unsupported Kubernetes Cut-off||Oldest working version||One defaults-only E2E for the oldest Kubernetes version known to work with Submariner. This tests the cut-off version used by
Some versions of software used by the Shipyard base image are maintained manually and should be periodically updated.
ENV LINT_VERSION=<version> \ HELM_VERSION=<version> \ KIND_VERSION=<version> \ BUILDX_VERSION=<version> \ GH_VERSION=<version> \ YQ_VERSION=<version>
All our projects use GitHub actions. These include dependencies which should be regularly checked for updates. Dependabot should be used to submit PRs to keep all GitHub Actions up-to-date. Hash-based versions should always be used to ensure there are no changes without an update on our side.
For example, this GitHub Action dependency:
steps: - name: Check out the repository uses: actions/[email protected] with: fetch-depth: 0
Would be updated by this Dependabot configuration:
--- version: 2 updates: - package-ecosystem: github-actions directory: '/' schedule: interval: daily
Dependabot will only submit updates when projects make releases. That may leave CI broken waiting on a release while a fix is available.
If a project has a fix but has not made a release that includes it, we should manually update the SHA we consume to include the fix.
In particular, some projects “release” fixes by moving a tag to a point in git history that includes the fix.
They assume versioning like
Again, we should always use SHA-based versions, not moveable references like tags, to help mitigate supply-chain attacks.