Opinionated GitHub Actions and reusable workflows to build, test, sign, and distribute container images and Helm charts. The goal is to offer a consistent supply-chain friendly pipeline for OCI assets managed within GitHub Actions.
Actions that operate on OCI images across their build, metadata, and lifecycle management phases.
Actions dedicated to packaging, validating, and publishing Helm charts for Kubernetes deployments.
Orchestrated workflows you can plug directly into repositories to automate container-focused CI routines.
Contributions are welcome! Please review the contributing guidelines before opening a PR.
All actions follow a consistent layout:
actions/{category}/{action-name}/
├── action.yml # Action definition with inputs/outputs
├── README.md # Usage documentation and examples
└── index.js / scripts # Optional Node.js helpers (when required)
- Consistent branding: Use
author: hoverkraftwithcolor: blueand a meaningfulicon. - Pinned dependencies: Reference third-party actions via exact SHAs to guarantee reproducibility.
- Input validation: Validate critical inputs early within composite steps or supporting scripts.
- Idempotent steps: Ensure actions can run multiple times without leaving residual state in the workspace.
- Multi-platform support: Test actions in both
ubuntu-latestandwindows-latestrunners when applicable. - Cross-platform compatibility: Uses
actions/github-scriptsteps for cross-platform compatibility. Avoidrunsteps. - Logging: Use structured logs with clear prefixes (
[build-image],[helm-test-chart], …) to simplify debugging. - Security: Avoid shell interpolation with untrusted inputs; prefer parameterized commands or
set -euo pipefailwrappers.
- Dockerfile: Provides the Super Linter environment with UID/GID passthrough for local dev parity.
- Tests: Located in
tests/with fixtures for container builds and chart-testing scenarios. - Workflows: Reusable definitions live in
.github/workflows/; internal/private workflows are prefixed with__.
- Encapsulate reusable logic in modules under the action directory (for example,
actions/my-action/index.js). - Prefer async/await with explicit error handling when interacting with the GitHub API or filesystem.
- Centralize environment variable parsing and validation to keep composite YAML lean.
- Prefer multi-architecture builds via
docker buildx buildwith explicit--platformlists. - Surface provenance metadata through outputs (
image-name,digest, etc.) to unblock downstream jobs. - Keep secrets and registry credentials in GitHub environments or organization secrets—never hardcode them.
- Use the chart fixtures under
tests/charts/to exercise Helm-focused actions. - Maintain
Chart.lockfiles alongsideChart.yamlto document dependency revisions. - Commit
ci/empty-values.yamltemplates for creating scenario-specific overrides.
make lint # Run the dockerized Super Linter
make lint-fix # Attempt auto-fixes for lint findings
# Container & Helm validation helpers
make test-build-application # Build and push the sample test application image
make test-ct-install # Validate Helm charts via chart-testing🏢 Hoverkraft [email protected]
- Site: https://hoverkraft.cloud
- GitHub: @hoverkraft-tech
This project is licensed under the MIT License.
SPDX-License-Identifier: MIT
Copyright © 2025 hoverkraft-tech
For more details, see the license.