LABEL block reads better when keys appear in a stable, logical
order. This rule reorders pairs inside a single LABEL instruction so that
related image metadata stays grouped and diffs stay small.
Description
Image metadata reads best when keys cluster by purpose. The defaultoci-logical order follows how reviewers usually scan a LABEL block:
The
lexical order is a flat alphabetical comparator across all keys.
The rule reports when a single multi-pair LABEL instruction has at least two
pairs and the configured comparator says they are not in stable order.
Auto-fix
The fix swaps the source text of individualkey=value spans inside the
existing LABEL, leaving continuation backslashes, indentation, and any
surrounding whitespace untouched. Per-pair edits are narrow on purpose so they
can co-run with tally/labels/prefer-grouped
and tally/newline-per-chained-call
without conflicts.
The fix is suppressed when:
- The
LABELis single-line multi-pair. Lettally/newline-per-chained-callsplit it onto continuation lines first; the next lint pass then reorders. - A comment line splits the pairs. Comments mark intentional sections, and the v1 fixer never crosses them.
- The block contains a duplicate key. Defer to
tally/labels/no-duplicate-keys; reordering duplicates would change the effective image metadata. - A pair has a dynamic key, an empty key, an expansion error, or uses the
legacy
LABEL key valueform.
Examples
Bad
Good
Configuration
Related Rules
tally/labels/no-duplicate-keys— must run first when a duplicate would otherwise change the effective image metadata after reordering.tally/labels/prefer-grouped— cooperative: combines scatteredLABELinstructions into one multi-line block; this rule then reorders the pairs inside that block.tally/newline-per-chained-call— splits single-line multi-pairLABELinstructions onto continuation lines so this rule can reorder them on the next lint pass.tally/labels/valid-keytally/labels/no-buildx-git-overlaptally/labels/no-stale-base-digest