Context
PR #993 introduced SHA-pinned action references and hadolint Dockerfile linting across 4 CI workflows (pr.yml, stage.yml, release.yml, pages.yml). CodeRabbit flagged the resulting duplication as a maintainability concern.
Recommendations
1. Extract hadolint into a reusable workflow or composite action
The hadolint/hadolint-action step with .hadolint.yaml config is currently duplicated in pr.yml, stage.yml, and release.yml.
Right now: ~7 lines per workflow. If the action version or hadolint rules change, 3 files must be updated.
Option A — Composite action (actions/hadolint/action.yml):
- Parameters:
dockerfile (string, default: Dockerfile)
- Runs the hadolint action step with project
.hadolint.yaml
- Pros: simple, no new
.github/workflows/ files
- Cons: only supports
runs-on: ubuntu-latest runner
Option B — Reusable workflow (.github/workflows/hadolint.yml):
- Triggered via
workflows:
- Parameters:
dockerfile (string, default: Dockerfile)
- Pros: can target different runners, more flexible
- Cons: requires extra workflow file
2. Extract pinned action SHAs into a Central Source
All 34 uses: references with inline version comments are duplicated across 4 workflows. Currently each workflow independently tracks pinned SHAs with version comments like # v6 or # v4.1.0.
If an action has a security vulnerability and needs a SHA bump, all 4 files must be updated manually.
Option A — Reusable workflow for common steps:
- Common steps like
actions/checkout, actions/setup-python, actions/cache, docker/setup-qemu-action, docker/setup-buildx-action, docker/login-action could be wrapped in reusable workflows with pinned SHAs as input parameters.
Option B — Shared YAML snippets (_shared/ directory):
- YAML anchors or external templates with pinned SHAs.
- Pros: simple, doesn't add abstraction
- Cons: limited flexibility with
with: parameters
Option C — GitHub Actions metadata (no-op approach):
- Maintain SHAs in a single
actions/versions.yml or similar config file referenced by CI.
- Cons: not natively supported, adds implementation complexity.
References
Context
PR #993 introduced SHA-pinned action references and hadolint Dockerfile linting across 4 CI workflows (pr.yml, stage.yml, release.yml, pages.yml). CodeRabbit flagged the resulting duplication as a maintainability concern.
Recommendations
1. Extract hadolint into a reusable workflow or composite action
The
hadolint/hadolint-actionstep with.hadolint.yamlconfig is currently duplicated in pr.yml, stage.yml, and release.yml.Right now: ~7 lines per workflow. If the action version or hadolint rules change, 3 files must be updated.
Option A — Composite action (
actions/hadolint/action.yml):dockerfile(string, default:Dockerfile).hadolint.yaml.github/workflows/filesruns-on: ubuntu-latestrunnerOption B — Reusable workflow (
.github/workflows/hadolint.yml):workflows:dockerfile(string, default:Dockerfile)2. Extract pinned action SHAs into a Central Source
All 34
uses:references with inline version comments are duplicated across 4 workflows. Currently each workflow independently tracks pinned SHAs with version comments like# v6or# v4.1.0.If an action has a security vulnerability and needs a SHA bump, all 4 files must be updated manually.
Option A — Reusable workflow for common steps:
actions/checkout,actions/setup-python,actions/cache,docker/setup-qemu-action,docker/setup-buildx-action,docker/login-actioncould be wrapped in reusable workflows with pinned SHAs as input parameters.Option B — Shared YAML snippets (
_shared/directory):with:parametersOption C — GitHub Actions metadata (no-op approach):
actions/versions.ymlor similar config file referenced by CI.References