This page documents the maintenance of Submariner’s CI/CD for developers.
We have built some custom GitHub Actions in Shipyard for project-internal use. They have dependencies on public GitHub Actions that need to be periodically updated.
[~/go/src/submariner-io/shipyard/gh-actions]$ grep -rni uses e2e/action.yaml:77: uses: submariner-io/shipyard/gh-actions/restore-images@devel release-images/action.yaml:17: uses: docker/setup-qemu-action@e81a89b1732b9c48d79cd809d8d81d79c4647a18 release-images/action.yaml:19: uses: docker/setup-buildx-action@4b4e9c3e2d4531116a6f8ba8e71fc6e2cb6e6c8c cache-images/action.yaml:14: uses: actions/cache@88522ab9f39a2ea568f7027eddc7d8d8bc9d59c8 restore-images/action.yaml:18: uses: actions/cache@88522ab9f39a2ea568f7027eddc7d8d8bc9d59c8
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/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f 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.
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>
Some software used by Shipyard’s linting image are pinned to avoid unplanned changes in linting requirements, which can cause disruption. These versions should be periodically updated.
ENV MARKDOWNLINT_VERSION=0.33.0 \ GITLINT_VERSION=0.19.1