Files
computer-playbook/roles/sys-lint
kevinveenbirkenbachandClaude Opus 5 7bc12e55f3 fix(docs): drop the generated sections the designer merge put back
aceb5295ef moved Cosmos, Quick Setup and Credits out of the committed role
READMEs and into the documentation build's own scratch checkout, so a
committed copy can no longer go stale when the metadata moves. Merging
feature/designer (ebad39422c) took origin/main's side of those files, which
still carries them, and reinstated all 290 along with the cosmos make target
and its i8cos alias. tests/lint/ansible/roles/test_readme.py hard-fails on a
committed copy, and the reinstated Credits block credited one person with two
URLs, which tripped the credits-attribution lint as well.

Stripped with the repository's own fence-aware parser against
MANAGED_SECTIONS, not with a line filter: the Cosmos block holds a mermaid
fence a naive filter would cut through. The result is byte-identical to
aceb5295ef for every README that carries no prose change since.

The cosmos target wrote the forbidden section straight back into the
checkout, so it goes with them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-10-06 01:50:43 +02:00
..
…

Lint

Description

This role is the single point of truth for the release pins of the lint tools that the toolchain installs from GitHub releases: actionlint, hadolint and shfmt.

It deploys nothing. Its only content is meta/services.yml, which records the repository and ref of every pinned tool.

Overview

make install-lint used to ask GitHub for each tool's latest tag at install time. That made every installation depend on the network resolving api.github.com, and it silently changed the linter version between two runs of the same commit. Pinning moves the version into the repository, where it is reviewable and reproducible.

Because the pins use the same (repository, ref) shape as every other meta/services.yml, the existing update-repository-refs CI job discovers them on its own: it resolves the newest semver tag of each repository via git ls-remote --tags and opens a pull request with the bump. Upgrading a linter is therefore a reviewed commit, not a surprise.

Features

  • Reproducible installs: every tool resolves to the pinned ref, so the same commit installs the same linter version on every host and in every CI run.
  • Offline-tolerant: no tag lookup at install time, so a DNS or API outage no longer breaks make install-lint.
  • Automatically updated: the update-repository-refs job bumps the pins to the newest semver tag and opens a pull request.
  • One override per tool: ACTIONLINT_VERSION, HADOLINT_VERSION and SHFMT_VERSION override the pin for a one-off install without editing the role.

Usage

The pins are read by utils/install/lint/pinned.py, which every lint installer calls:

from utils.install.lint.pinned import resolve_release

slug, version = resolve_release("actionlint")

To pin a different version by hand, edit the tool's ref in meta/services.yml. To add a tool, add an entry with its repository and ref — the CI updater picks it up without further wiring.