Skip to content

chore: introduce locked mise toolchain - #6

Draft
JourneyOfLife wants to merge 3 commits into
mainfrom
codex/mise-adoption-2026-11-03
Draft

JourneyOfLife wants to merge 3 commits into
mainfrom
codex/mise-adoption-2026-11-03

Conversation

@JourneyOfLife

Copy link
Copy Markdown
Contributor

Adds exact tool versions, a generated Linux x64 mise.lock, onboarding notes and an additive toolchain smoke workflow. Existing application, security and deployment workflows are preserved.

Validation: locked installation and version diagnostics passed locally with mise 2026.10.25. The mise release archive digest was verified; CI pins the setup action by commit and verifies the extracted binary SHA-256. Existing full repository checks remain for CI/review.

Draft scope: Linux x64 toolchain adoption, not full application CI migration or compliance certification. Other platforms need generated locks and validation. No production tasks, secret loading, branch protection changes or automatic merge.

Pin repository tools and add isolated Linux installation verification while preserving existing checks and deployment workflows.
… property (ADR-0010 M-01, M-02)

Adds .miserc.toml with ceiling_paths set to the parent of the repository root, and
[tool_config] locked = true to mise.toml, plus a four-leg refusal test in the mise
workflow. jolarca-control proved the same pattern green on run 41677451440; this
repository's own run is the evidence for this repository.

Why each file: mise loads config from the filesystem root down to the cwd and
merges [tools] per tool, so an unbounded search lets a stray parent mise.toml add
tools that CI never sees -- the same commit resolving differently per machine. The
setting cannot live under [settings] in mise.toml because mise reads .miserc.toml
first, and the ceiling must name the parent because a ceiling directory is not
searched itself. locked = true makes strict lockfile mode a property of this
repository rather than of the CI job's --locked flag.

The guard reads the declared tool set out of mise.toml instead of naming versions,
so one file is correct across the fleet. Each negative leg is paired with a
positive one, because a guard asserting only absence also passes when the command
printed nothing.

Limits, in MISE-ADOPTION.md: Linux x64 only, CI only, no secrets, not a required
check; a project .miserc.toml cannot ignore global or system config, so ADR-0010
M-04 stays open; ceiling_paths fails open if the template does not render, silently,
and leg 2 is what turns the declaration into a control.
…he fleet

Propagating the guard broke `ci` in jolarca-data and jolarca-legal, and only in
those two, which is the whole point: their ci job runs yamllint with
line-length max 140, while jolarca-control's .yamllint allows 160. The file I
wrote passed locally at 160 and failed at 140 on line 167 (141 characters). Proven
as mine, not pre-existing, by the A/B on the same workflow: jolarca-legal ci was
success at 61102be5 and failure at c13a8c4f with only my commit between.

Three message lines rewrapped; the file's longest line is now 119 characters, which
passes 140 and 120 as well as 160. Verified before pushing with yamllint at all
three limits plus each repository's own .yamllint.

This is ADR-0010's own argument applied to the toolchain guard: one file is judged
by different rules in different repositories, so the portable artifact has to be
written to the strictest limit in the fleet rather than to the local one.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant