docker-base-images

Opinionated Docker base images.

This repository offers:

• a set of Docker base images that can be used as a foundation for building other Docker images.
• GitHub Actions and reusable workflows to help you build and publish your own "Docker base images" repository.

Our images

argocd-cmp-hk-deployment

ci-helm

A Docker image with all the tools needed to validate an helm chart

• helm chart-testing (aka ct)
• helm kubeconform plugin

mydumper

An image with an opiniated mydumper command as entrypoint

Actions

Actions that you can plug directly into your own Docker images repository.

- Get available images

- Should build images

Reusable Workflows

Get available images matrix

Orchestrated workflows you can plug directly into your own Docker images repository.

- Continuous Integration

- Prune pull requests images tags

- Get available images matrix

Contributing

Contributions are welcome! Please see the contributing guidelines for more details.

Action Structure Pattern

All actions follow this consistent structure:

actions/{category}/{action-name}/
├── action.yml          # Action definition with inputs/outputs
├── README.md          # Usage documentation
└── *.js              # Optional Node.js scripts (e.g., prepare-site.js)

Development Standards

Action Definition Standards

1. Consistent branding: All actions use author: hoverkraft, icon: <specific-icon>, color: blue
2. Composite actions: Use using: "composite" with GitHub Script for complex logic
3. Pinned dependencies: Always pin action versions with SHA (e.g., @ed597411d8f924073f98dfc5c65a23a2325f34cd)
4. Input validation: Validate inputs early in GitHub Script steps

JavaScript Patterns

• Class-based architecture: Use classes like AssetManager for complex functionality
• Path utilities: Extensive use of Node.js path module for cross-platform compatibility
• Regular expression patterns: Define constants for reusable patterns (MARKDOWN_IMAGE_REGEX, HTML_IMAGE_REGEX)
• Caching: Implement Map-based caching for expensive operations

Development Workflow

Prerequisites

• Docker
• Make

Linting & Testing

make lint        # Run Super Linter (dockerized)
make lint-fix    # Auto-fix issues where possible

# Run tests for a specific image
make test ci-helm      # Build and test ci-helm image
make test mydumper     # Build and test mydumper image

# Run tests for all images
make test-all          # Build and test all images with tests

# Use GitHub Actions locally with `act`
gh act -W .github/workflows/workflow-file-to-test.yml

File Conventions

• Dockerfile: Uses Super Linter slim image for consistent code quality
• Tests: Located in images/<image-name>/container-structure-test.yaml using container-structure-test
• Workflows: Private workflows prefixed with __ (e.g., __main-ci.yml)

Action Development Conventions

Always follow these patterns when creating/modifying actions:

1. Pinned Dependencies: Use exact SHA commits for all action dependencies:

   uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0

2. Consistent Branding: Every action.yml must include:

   author: hoverkraft
   branding:
     icon: <specific-icon>
     color: blue

3. Input Validation: Always validate inputs early in GitHub Script steps:

   const urlInput = ${{ toJson(inputs.url ) }};
   if (!urlInput) {
     return core.setFailed("URL input is required.");
   }

JavaScript Development Patterns

For Node.js scripts (like prepare-site.js):

• Use class-based architecture for complex functionality
• Define regular expression patterns as constants (MARKDOWN_IMAGE_REGEX, HTML_IMAGE_REGEX)
• Implement Map-based caching for expensive operations
• Always use Node.js path module for cross-platform compatibility

File Structure Understanding

actions/{category}/{action-name}/     # Modular action organization
├── action.yml                        # Action definition with inputs/outputs
├── README.md                         # Usage documentation
└── *.js                             # Optional Node.js scripts

.github/workflows/                    # Reusable workflows
├── deploy-*.yml                      # Deployment orchestration
├── clean-deploy-*.yml               # Cleanup workflows
└── __*.yml                          # Private/internal workflows

tests/                               # Expected vs actual comparisons
└── argocd-app-of-apps/             # Template testing structure

Continuous Integration

Pull requests

Pull requests checks

• Validate that pull request title respects conventional commit
• Run linters against modified files

Pull requests build

• Build images that have been modified
• Tag with Pull request number and commit sha

Pull requests cleaning

• Remove all tags create during Pull request builds

Release

Release checks

• Run linters against modified files

Release build

• Build images that have been modified
• Tag respecting sementic versioning

Author

🏢 Hoverkraft contact@hoverkraft.cloud

• Site: https://hoverkraft.cloud
• GitHub: @hoverkraft-tech

License

This project is licensed under the MIT License.

SPDX-License-Identifier: MIT

Copyright © 2025 hoverkraft-tech

For more details, see the license.