Strimzi GitHub Actions

Shared GitHub Actions and CI workflows used across Strimzi repositories.

Important

All the actions within this repository are designed for internal usage within Strimzi projects. We do not support usage of the actions outside the Strimzi organization.

Actions

Dependency Actions

Actions for installing tools and setting up Kubernetes clusters.

Action	Description	Key Inputs
dependencies/install-docker	Sets up Docker with QEMU and Buildx for multi-platform builds	—
dependencies/setup-java	Installs Java and Maven	javaVersion (21), mavenVersion (3.9.9), javaDistro (temurin)
dependencies/install-helm	Installs Helm and helm-unittest plugin	helmVersion (v3.20.0), helmUnitTestVersion (v1.0.3)
dependencies/install-yq	Installs yq YAML processor	version (v4.6.3), architecture (amd64)
dependencies/install-shellcheck	Installs ShellCheck linter	version (0.11.0), architecture (amd64)
dependencies/install-syft	Installs Syft SBOM generation tool	version (1.20.0), architecture (amd64)
dependencies/install-ascii-doctor	Installs Ascii Doctor tool	rubyVersion (3.2)
dependencies/setup-kind	Creates a Kind cluster with local registry and cloud-provider-kind	kindVersion (0.31.0), controlNodes (1), workerNodes (1), cloudProviderVersion (0.6.0)
dependencies/setup-minikube	Creates a Minikube cluster with local registry	minikubeVersion (v1.38.0), kubeVersion (v1.38.0)

Build Actions

Actions for building, testing, and releasing Strimzi components.

Action	Description	Key Inputs
build/build-binaries	Builds and tests Java binaries using Makefile targets	clusterOperatorBuild (false), mainBuild (true), artifactSuffix (binaries)
build/build-containers	Builds and archives container images	architecture (amd64), imagesLocation (required), containerTag (latest)
build/push-containers	Pushes container images and creates multi-arch manifests	architectures (required), registryUser (required), registryPassword (required)
build/load-containers	Loads container images into Kind/Minikube registry	registry (required: minikube/kind/external)
build/deploy-java	Deploys Java artifacts to Maven Central	projects (required), settingsPath (required)
build/release-artifacts	Builds release artifacts using Makefile	releaseVersion (required), artifactSuffix (required)
build/publish-helm-chart	Publishes Helm Chart as OCI artifact	releaseVersion (required), helmChartName (required). Outputs: image (full OCI ref with digest)

Important

Build actions do not install their own dependencies (Java, yq, Helm, Docker, Shellcheck, Syft, etc.). Callers must install the required dependencies using the appropriate dependency actions before invoking a build action.

Important

The build-binaries action supports an clusterOperatorBuild input (default false) that enables Strimzi Kafka Operator specific build steps — Helm chart generation, CRD distribution, dashboard setup, documentation checks, and uncommitted changes verification. Other repositories should leave this disabled.

Artifact Attestation

Artifact attestation is handled by the reusable-attest.yml reusable workflow, which creates SLSA build provenance and SBOM attestations using GitHub's Attestation API (actions/attest). Attestations are signed with Sigstore (keyless, via GitHub OIDC) and stored in the GitHub Attestation API. Consumers verify with gh attestation verify.

Attestation runs as a separate workflow job — if it fails, the release/push/helm artifacts are already published and remain available.

The reusable workflow handles three types of attestation:

Job	What it attests	Key inputs
attest-release	Release archives (.tar.gz, .zip, .tgz)	artifactSuffix, releaseVersion
attest-helm	Helm OCI artifact	helmChartName, helmChartImage (full OCI ref with digest)
attest-containers	Container images (matrix) + SBOMs	containerImages (JSON array), sbomsArtifact

The attest-release job downloads the release tar, attests the archives, adds the .intoto.jsonl provenance bundle and SBOMs to the tar, and re-uploads it (required for OpenSSF Scorecard Signed-Releases check).

Required permissions in the calling workflow:

permissions:
  contents: read
  id-token: write       # OIDC token for Sigstore signing
  attestations: write   # GitHub Attestation API

Example — add to your project's release.yml after the push-containers and publish-helm jobs:

  attest:
    needs: [push-containers, release-artifacts, publish-helm]
    uses: strimzi/github-actions/.github/workflows/reusable-attest.yml@main
    with:
      containerImages: ${{ needs.push-containers.outputs.images }}
      artifactSuffix: "operators"
      releaseVersion: ${{ env.RELEASE_VERSION }}
      helmChartName: "strimzi-kafka-operator"
      helmChartImage: ${{ needs.publish-helm.outputs.image }}
      sbomsArtifact: ${{ needs.push-containers.outputs.sbomsArtifact }}

Verification

# Release archives
gh attestation verify <artifact-file> --repo strimzi/<project>

# Container images
gh attestation verify oci://quay.io/strimzi/<image>@<digest> --repo strimzi/<project>

# Helm charts
gh attestation verify oci://quay.io/strimzi-helm/<chart>@<digest> --repo strimzi/<project>

Security Actions

Actions for security scanning of dependencies and container images.

Action	Description	Key Inputs
security/snyk-maven-scan	Run Snyk scan on Maven dependencies with SARIF upload	scanName (required), snykMonitor, exclude
security/snyk-container-scan	Scan a container image with Snyk, upload results to Code Scanning	imageFile (required), image (required), snykMonitor
security/fossa-maven-scan	Run FOSSA scan on Maven dependencies for license and vulnerability analysis	scanName (required), fossaTest, exclude
security/fossa-container-scan	Scan a container image with FOSSA for license and vulnerability analysis	imageFile (required), image (required), fossaTest

Utils Actions

Actions used as utils mostly in operators repository.

Action	Description	Key Inputs
utils/check-permissions	Check whether users who leave the comment has rights to trigger actions	none
utils/determine-ref	Determine checkout ref based on PR metadata	none
utils/should-run	Determine whether STs pipeline should be run or not based on comment body	none

Test Workflows

test-dependencies.yml

Tests all dependency actions with version matrix combinations:

• Docker — Buildx multi-platform support verification
• Helm — version matrix, unittest plugin verification
• ShellCheck — version matrix, functional test
• Syft — version matrix
• yq — version matrix, functional test
• Java/Maven — Java 17/21 + Maven 3.9.9/3.8.8 matrix
• Kind — single/multi-node clusters, K8s version verification, registry access from inside cluster, node labels, cloud-provider-kind
• Minikube — version matrix with latest, K8s version verification, registry access

test-integrations.yml / reusable-test-integrations.yml

End-to-end integration tests that run the full build pipeline (build binaries, deploy Java, build/push containers, release artifacts, publish Helm) against multiple Strimzi repositories:

• strimzi-kafka-operator (with clusterOperatorBuild: true)
• strimzi-kafka-bridge
• kafka-access-operator
• strimzi-mqtt-bridge
• drain-cleaner
• client-examples
• kafka-quotas-plugin

Warning

The rest of Strimzi repositories are not compatible yet and will be added in the future.

Usage

Reference actions from another Strimzi repository:

- uses: strimzi/github-actions/.github/actions/dependencies/setup-kind@main
  with:
    controlNodes: 1
    workerNodes: 3

Cross-repo testing

With shared repository with our specific actions we unfortunately have chicken-egg problem for several parts of the build process. In case we do update push-container or release flows in respective repositories, we are not able to catch issues during the PRs with current checks. The result will be shown only in tests within github-actions repository, because it tests flow for all parts of build process. To mitigate this, we have to run the same integration tests we have in this repository also in other repositories, just with different configurations.

The main difference is in githubActionsRef parameter. This parameter says which branch of github-actions repo will be used for running the tests which should align with branch or version used in build/release workflows. So for example in case we use version 1.0.0 in build workflow, we should keep the same in the tests to ensure that current actions will work with new changes.

The following code snippet shows the workflow for Bridge repository:

name: Test github-actions integration

on:
  pull_request:
    branches:
      - "*"
  push:
    branches:
      - "main"

permissions:
  contents: read
  id-token: write
  attestations: write

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test-github-actions-integration:
    uses: strimzi/github-actions/.github/workflows/reusable-test-integrations.yml@main
    with:
      repo: ${{ github.repository }}
      ref: ${{ github.sha }}
      architecture: "amd64"
      artifactSuffix: "kafka-bridge"
      buildContainers: true
      modules: "./"
      nexusCheck: "kafka-bridge"
      javaVersion: "17"
      helmChartName: "none"
      releaseVersion: "6.6.6"
      imagesLocation: "kafka-bridge-amd64.tar.gz"
      clusterOperatorBuild: false
      githubActionsRef: "1.0.0"
    secrets: inherit

Versioning

This repository uses vX.Y release tags (e.g., v1.0, v1.3) with floating vX major tags that always point to the latest release within a major version. Releases are created from release-X.x branches using an automated workflow. See RELEASE.md for full details on the versioning scheme and release process.

Warning

To ensure that actions remain functional across all Strimzi projects, compatibility between N and N-1 versions of the github-actions repository must be maintained. This must be honored by every change made after the first release.

License

This project is licensed under the Apache License 2.0.