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.
- Setup
Actions dedicated to packaging, validating, signing, 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.
Dependabot manages dependencies in supported manifests.
Renovate manages the annotated Buildx and BuildKit defaults in
Docker Setup, using GitHub releases and Docker image tags respectively.
The Renovate workflow runs
renovatebot/github-action every Friday at 04:23 UTC
and supports manual runs through workflow_dispatch. It reads the configuration from the default
branch and groups updates into pull requests with a minimum release age of seven days.
Updates require review and CI validation before merging.
The workflow uses the CI_BOT_APP_CLIENT_ID variable and CI_BOT_APP_PRIVATE_KEY secret
from the repository or organization. The CI bot must be installed on this repository with
read access to checks and write access to contents, issues, pull requests, and commit statuses.
Its installation token is scoped to this repository, and Renovate uses GitHub API commits for signing.
Validate configuration changes with a Node.js version supported by Renovate:
npx --yes --package renovate renovate-config-validator --strict --no-global .github/renovate.jsonmake ci # Run all CI checks
# Linting helpers
make lint # Run the dockerized Super Linter
make lint-fix # Attempt auto-fixes for lint findings
make npm-audit-fix # Fix npm audit issues in action packages
make npm-update # Interactively update npm dependencies in action packages
# 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-testingThe repository includes comprehensive end-to-end tests for all local GitHub Actions. These tests follow an Arrange-Act-Assert pattern:
- Arrange: Set up test fixtures and inputs (e.g., checkout code, prepare test context)
- Act: Execute the action being tested with specific inputs
- Assert: Validate outputs match expected values using
actions/github-script
Test workflows are located in .github/workflows/__test-action-*.yml and .github/workflows/__test-workflow-*.yml. They run on:
- Push to
mainbranch - Push to tags (e.g.,
v1.0.0) - Pull request events
- Scheduled runs (weekly)
Tag-specific behavior: When tests run on tag pushes, assertions dynamically adapt to expect the tag name (e.g., v1.0.0) instead of branch names. This ensures tests pass in all trigger contexts without hardcoding expected values.
🏢 Hoverkraft contact@hoverkraft.cloud
- 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.