Skip to content

[feature] Full dockerfilelint integration #82

Description

@paudley

Summary

Add full coding-ethos integration for dockerfilelint from the pyqa_lint catalog.

Parent tracker: #77

pyqa_lint source: ~/Active/pyqa_lint/tooling/catalog/languages/docker/dockerfilelint.json

Scope

This issue covers one tool only. Integration is complete only when coding-ethos owns acquisition, execution, diagnostics, Dockerfile language facts, CEL/SARIF output, policy alignment, MCP/agent visibility, docs, and tests.

Required Integration Surface

1. Tool Acquisition

  • Add deterministic managed acquisition for dockerfilelint.
  • Pin the version and checksum where a release artifact is downloaded.
  • Record provenance in the managed toolchain manifest.
  • Validate the acquired executable during bootstrap and fail fast with a structured diagnostic if validation fails.
  • Do not rely on an arbitrary host-installed dockerfilelint from PATH.

2. Command Orchestration

  • Build command construction in Go through the hook runner or managed capture path.
  • Select staged/changed targets when safe; if dockerfilelint requires project-level execution, document the reason and isolate the scope.
  • Pass config paths explicitly and log the selected source of truth.
  • Respect sandboxing, timeout, filesystem, and network policy.
  • Avoid shell glue and Go-to-shell-to-Go execution paths.

3. Diagnostics Parsing

  • Parse native dockerfilelint output into normalized diagnostics with tool, file, line, column, severity, rule/code, and message.
  • Convert unparseable output into structured tool-failure diagnostics.
  • Preserve raw output in traces without flooding TOON or MCP summaries.
  • Add parser fixtures for success, warning/error severity mapping, empty output, and malformed output.

4. Language AST Facts

  • Confirm Tree-sitter/AST fact support for Dockerfile files is sufficient for policy context and SARIF locations.
  • Extend shared AST fact collection first if policy context is missing.
  • Do not add ad hoc text scanners or policy-specific AST walkers before checking the AST/CEL/SARIF architecture path.
  • Add fixtures proving representative Dockerfile files can be indexed, or explicitly document why AST facts are not applicable for this tool.

5. CEL and Policy Alignment

  • Expose dockerfilelint findings through the existing CEL diagnostic inputs by tool, rule/code, file, severity, and path metadata.
  • Add policy mappings only where coding-ethos has a clear repo-trust, maintainability, security, or safety opinion.
  • Align actionable findings with relevant ethos principles and remediation skills.
  • Keep advisory versus blocking behavior explicit and configurable.

6. SARIF Integration

  • Emit SARIF with stable ruleId, source tool metadata, severity, and location data.
  • Include related locations, fixes, or help text when dockerfilelint exposes them.
  • Add SARIF shape tests for at least one real diagnostic.
  • Preserve stable identities so CI, PR review, and IDE surfaces can correlate findings over time.

7. MCP and Agent Surface

  • Ensure lint_check, lint_advice, SARIF remediation, risk summary, trend analysis, and hook traces identify dockerfilelint correctly.
  • Add capability metadata for file reads, file writes, tool execution, network use, autofix support, and advisory/blocking role.
  • Make failure modes actionable for agents and human contributors.

8. Docs and Config

  • Document managed acquisition, config source of truth, generated config behavior, and common remediation guidance.
  • Update README/tooling docs and examples for the Dockerfile path.
  • If coding-ethos generates config for dockerfilelint, add drift checks and hash manifest entries.

Acceptance Criteria

  • dockerfilelint is acquired through the managed toolchain with version/checksum/provenance recorded where applicable.
  • The hook runner or managed capture path invokes dockerfilelint without shell glue or implicit host config discovery.
  • Native diagnostics are parsed into normalized diagnostics and SARIF.
  • AST/language fact support for Dockerfile is present or explicitly documented as not applicable.
  • CEL policy inputs can reason over dockerfilelint findings by tool/code/file/severity.
  • MCP lint and SARIF advice surfaces include dockerfilelint output cleanly.
  • Documentation explains config ownership and expected operator workflow.
  • Unit tests cover acquisition, command construction, parser success, parser failure, and SARIF shape.
  • A functional workflow test exercises dockerfilelint on a representative fixture.
  • make build, make pre-commit, and relevant Go package tests pass.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions