Skip to content

rainix-static: allowlist file extensions at the repo level #261

Description

@thedavidmeister

What

Add a static check to the rainix shared static suite (rainix-sol / rainix-rs static) that fails CI when a repo contains a tracked file whose extension is not on a configured allowlist.

Why

The org's toolchain is Rust / nix / forge / Solidity (the flake composes rainix; the dev shell provides forge, slither, prettier, the rust toolchain — no Python, no ad-hoc interpreters). Off-convention file types slip in and rely on ambient GitHub-runner tooling that isn't in the nix dev shell and isn't reproducible via nix develop.

Concrete motivation: S01-Issuer/st0x.deploy#243 introduced script/gen_prod_libs.py — a Python codegen script wired into CI as run: python3 script/gen_prod_libs.py. It passed CI only because ubuntu-latest ships an ambient python3; it is invisible to nix develop and off-convention. An extension allowlist would have red-flagged the .py at the PR, forcing the logic into forge/rain-sol-codegen or a nix-packaged Rust binary instead.

Shape

  • A check over git ls-files (tracked files only) that rejects any extension not on an allowlist.
  • Default allowlist = the canonical org set (e.g. .sol .toml .nix .lock .md .yaml .yml .json .txt + license/dotfiles), configurable per-repo (an opt-in extra list for repos that legitimately need more).
  • Emit the offending path(s) so the fix is obvious.
  • Lives in rainix (shared CI), consumed via the existing static reusable — not inlined per-repo (per the 'rainix owns shared CI' convention).

Note

Complements the existing de-bash / nix-bins direction (standalone tools ship as flake packages invoked directly, never as bash/python wrappers) by making it enforceable rather than convention-only.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions