Skip to content

Hold .soldeerignore against the repo root, and stop shipping .audit/ - #133

Merged
thedavidmeister merged 8 commits into
mainfrom
2026-08-16-issue-91
Aug 17, 2026
Merged

Hold .soldeerignore against the repo root, and stop shipping .audit/#133
thedavidmeister merged 8 commits into
mainfrom
2026-08-16-issue-91

Conversation

@thedavidmeister

@thedavidmeisterthedavidmeister commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

Closes#91

No test guards this change, and it can regress silently

This PR ships no forge test. The check it used to carry —
test/package/SoldeerIgnore.t.sol, which listed the repo root and held
.soldeerignore against it in both directions — has been deleted, and the
repo-root { access = "read", path = "./" }fs_permissions grant it needed has
been reverted, so fs_permissions is back to its base three entries.

That means: nothing in this repo will notice if this regresses. A new
top-level path can start shipping in the soldeer package because nobody added it
to .soldeerignore, and a .soldeerignore entry can go dead — matching nothing,
exactly the .vscode and /docs defect this PR fixes — and the suite will stay
green through either. There is no test to strengthen and no assertion to read;
the only thing standing between the package and the next leak is someone editing
.soldeerignore by hand, correctly, at the same time they add a root path.

The check is being rehomed to rainlanguage/rainix#317 — "Six repos' worth of
static analysis is being hand-rolled in Solidity because rainix-static has no
home for repo-wide lint checks". It is a repo-root packaging rule, not a
statement about any Solidity in src/, and it belongs in shared static analysis
that every rain repo gets, not in one repo's forge test reading its own
directory listing through a cheatcode. Until that lands, this is unguarded.

Why the test was here at all

The fixer brief that produced this PR said every fix ships a test and
verify-by-hand is never acceptable, with no exemption for changes that have no
behaviour. That was wrong and has been corrected. .soldeerignore is a
configuration file with no Solidity behaviour, and the test written to satisfy
that brief was hand-rolled static analysis in Solidity: 174 lines whose subject
was a directory listing and two text files, with two of its four tests asserting
only against its own hardcoded shipped() set — itself a hand-maintained second
definition of the package, which is the same class of defect as the
.soldeerignore drift it was written to catch.

What ships here

.soldeerignore, and nothing else: two dead entries out, one real exclusion in.
The change with the real consequence is that .audit/ stops shipping.

Dead entries, the finding as filed..vscode and /docs matched nothing and
never have — git log --all -- .vscode and git log --all -- docs are both
empty. Removed.

.audit/ was shipping. The audit stamp commit added .audit/runs.jsonl and
.audit/scope.json at the root. .soldeerignore excluded /audit but not
.audit, so both files are inside the published package. Confirmed against the
registry rather than inferred — unzip -Z1 on the current 0.1.25 zip pulled
from api.soldeer.xyz lists:

.audit/
.audit/runs.jsonl
.audit/scope.json

Now excluded via /.audit.

The issue's note about keeping .DS_Store is right and the entry is untouched:
nothing here produces it and git is not told about it, but macOS writes it into
any directory it browses.

meta/ is committed input: in git, and in the package

Two rulings, 2026-08-17, settle meta/ in both directions:

"in 133 meta should be committed, so it can't be in gitignore"

"for 133 meta needs to be in soldeer published packages"

An earlier revision of this PR contradicted both — it added meta to
.gitignore and /meta to .soldeerignore, on the premise that the directory
is test scratch like cache, dependencies and out. That premise is wrong and
both lines are gone.

meta/<name>.rain.meta is a committed input to codegen — it is the file
LibCodeGen.describedByMetaHashConstantString hashes into a consumer's
DESCRIBED_BY_META_HASH. Gitignoring the directory makes committing one
impossible. That none are committed in this repo today is a data gap to be filled
by adding files, never one to be enshrined by ignoring the path — and the same
holds for the published package, which is why /meta is not in .soldeerignore
either. meta/ is absent from .soldeerignore on main, so this PR leaves that
path exactly as main has it: whatever is committed under meta/ ships.

Dropping both lines costs nothing, which is the point:
LibCodeGenDescribedByMetaHashConstantStringTest removes every fixture it
writes, so the directory a full run leaves at the root is empty, and git does
not track empty directories. git status --porcelain is clean after forge test
on this branch — verified, not assumed.

Where the issue's proposed fix was incomplete

The issue said "delete lines 8 and 12" and it was right about those two lines. It
did not name .audit, and that entry would not have been found by reading the
list — it needed the published zip. It is the same defect the issue describes, so
it is fixed here.

Interaction with #121

#121 (issue #84) removed .gas-snapshot and its .soldeerignore entry; it has
since merged and is in the origin/main this branch merges. No conflict, textual
or semantic. With no test in this repo holding the list against the root, nothing
forces whichever change lands next to do both halves — dropping a file without
its entry, or an entry without its file, is silent in both directions. That is a
concrete instance of the regression this PR is unguarded against.

QA

Re-run on the current merge commit (origin/main = c816251, merged in — merge,
not rebase):

  • nix develop -c forge testRan 23 test suites: 155 tests passed, 0 failed, 0 skipped (155 total tests). This PR touches no Solidity, so it must not move
    the count, and it does not.
  • nix develop -c forge fmt --check — clean, no diff.
  • nix develop -c reuse lint — compliant; 51/51 files carry copyright and
    license information.
  • git status --porcelain — empty after a full forge test run. The meta/
    directory the suite leaves at the root holds no files, so git does not see it.
  • git diff origin/main is .soldeerignore alone: 1 insertion, 2 deletions.
  • foundry.toml is byte-identical to origin/main.
  • Oracle for what ships is the published package itself, not the source:
    unzip -Z1 over the 0.1.25 zip fetched from api.soldeer.xyz gives the
    actual shipped file list, and .audit/runs.jsonl and .audit/scope.json are
    in it, which is the leak. For the dead entries the oracle is
    git log --all -- .vscode and git log --all -- docs, both empty, so neither
    path has ever existed here.

thedavidmeisterand others added 2 commits August 16, 2026 18:55
…cumentation
`.vscode` and `/docs` matched nothing and never have; `.audit/` was at the root
and unexcluded, so its run stamps shipped in the package.
Closes#91
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Running the suite leaves an empty `meta/` at the root, which nothing excluded,
so it would ship in any package built after a test run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@thedavidmeisterthedavidmeister self-assigned this Aug 16, 2026
@coderabbitai

coderabbitaiBot commented Aug 16, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in:17 minutes

Limit details: You’ve used all 1 included review currently available under your plan.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: f5f71ac3-9c65-49cf-915e-62a59c6121bc

📥 Commits

Reviewing files that changed from the base of the PR and between c816251 and edfb864.

📒 Files selected for processing (1)
  • .soldeerignore

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

thedavidmeisterand others added 4 commits August 16, 2026 19:20
Delete `test/package/SoldeerIgnore.t.sol` and revert the repo-root
`{ access = "read", path = "./" }` fs_permissions grant, returning
`fs_permissions` to its base three entries.
The `.soldeerignore` and `.gitignore` changes stay: `.audit/` stops shipping and
`meta/` can no longer leak.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
meta/<name>.rain.meta is what
LibCodeGen.describedByMetaHashConstantString reads. Those files are
committed inputs to codegen, so gitignoring the directory makes
committing them impossible. There are none committed today; that is a
data gap to fill by adding files, not one to enshrine by ignoring the
path.
Costs nothing: LibCodeGenDescribedByMetaHashConstantStringTest removes
every fixture it writes, so the directory the suite leaves at the root
is empty and git does not see it. Verified: git status is clean after
a full run with the line gone.
/meta stays in .soldeerignore. What git tracks and what the published
package ships are different questions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
thedavidmeisterand others added 2 commits August 17, 2026 04:51
Ruled 2026-08-17: "for 133 meta needs to be in soldeer published
packages". .soldeerignore lists what is stripped from the package, so
`/meta` is removed. meta/ is absent from that list on main, so this
restores main's behaviour for that path and the published package
carries whatever meta/ holds.
This is the second half of the pair. The first ruling put meta/ in git
("in 133 meta should be committed, so it can't be in gitignore"); this
one puts it in the package. Committed and published, both.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for freeto 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.

.soldeerignore carries entries for .vscode and /docs, paths that have never existed in this repo

2 participants

@thedavidmeister@claude