docs: stop the README narrating rainix's workflow internals - #140
Conversation
The README restated how rainix's reusable workflows behave in four places: rainix-copy-artifacts' regeneration and hard-fail conditions, its regenerate/fmt/diff step order, a six-item transcription of rainix-sol-static.yaml's gates, and rainix-autopublish's publish/tag/bump sequence. Each was a second copy of a fact rainix owns, drifting independently of it with nothing here able to catch the drift. Cut each to the consequence a consumer must act on, plus a link to the workflow that owns the mechanism. The consumer-facing facts are unchanged: the build script must be script/Build.sol, consumers need line_length = 120 and tab_width = 4, [package].version is the next unpublished version and neither it nor the tag is set by hand, this repo passes soldeer-package explicitly, and local green is necessary but not sufficient. The two rewritten clauses that linked into .github/workflows/ now use full github.com URLs. .soldeerignore strips .github from the published package, so a repo-relative path there resolves to nothing for a reader holding the package. Closes #139 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 45 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 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. 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. Comment |
The paragraph this branch added documented a `max-codegen-passes` bound, a default of 5 and a `did not reach a fixed point` failure. None of them exist: rainix at HEAD 7f223b4 runs `forge script ./script/Build.sol` exactly once inside an `if [ -f ... ]` guard, `max-codegen-passes` has 0 hits across the whole repo, and the only failure that step emits is `Committed artifacts are stale`. rainlanguage/rainix#319, which would add the bound, is still open. State what is true instead: the loop is unbounded, nothing iterates it, and the operator regenerates until the working tree stops changing. Written in the register #140 established for this README (closing #139): the consequence for someone working in a consuming repo plus one link to the workflow that owns it, not a transcription of what that workflow does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Re-sites the orphaned-artifact refusal onto main's current `LibFs`: - `buildFileForContract` is now the six-arg call applied to `GENERATED_DIR` over a seven-arg `dir` overload (#112), builds the whole file content before touching disk (#100), and unlinks in a `while` loop (#127). The check goes into the shared body, after `vm.createDir` because it is a read of that directory, and before the unlink so a refusal leaves the existing artifact where it found it. - `requireNoOrphanedArtifact(vm, contractName)` is that check applied to `GENERATED_DIR`, over a private `requireNoOrphanedArtifactIn`, mirroring `pathForContract` / `pathForContractIn`. The overload reads the directory it writes into rather than always `GENERATED_DIR`. - The test moves from `test/lib/` to `test/src/lib/` (#56), and its calls carry the licence and copyright `filePrefix` now takes (#135). - `InvalidContractName` / `isContractNameSlow` are `InvalidIdentifier` / `isIdentifierSlow`, and forge-std is 1.16.2. - The README's "Generated paths" section anchors ahead of "Formatter requirements": the worked-example section it sat under is gone (#138) and the publish section it appended to was rewritten (#140). Drops the hand-set `[package].version = "0.2.0"` and the README paragraph that justified it. Autopublish owns the version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Closes #139.
The README restated how rainix's reusable workflows behave in four places. Each
was a second copy of a fact rainix owns, drifting independently of the thing it
described, with nothing in this repo's CI able to catch the drift. This cuts
each instance to the consequence a consumer must act on, plus a link to the
workflow that owns the mechanism.
The rule applied is the property #139 filed, not a list of four edits: the
README documents this package's own facts and choices; it does not restate the
behaviour of the third-party systems it uses. Same rule that closed PR #117
and issue #82 for soldeer's install semantics.
Clause by clause
Instance 1 — the build-script path (README:14-18)
script/Build.sol"rainix-copy-artifacts.yamlreusable regenerates fromscript/Build.solexactly"src/generated/without one"Instance 2 — formatter requirements (README:38-42)
LibCodeGenwraps the declarations it emits itself, deciding againstMAX_LINE_LENGTHandNEWLINE_DUE_TO_MAX_LENGTH"forge fmt'sline_lengthandtab_width, which this repo states in[fmt]offoundry.tomlrather than inheriting"[fmt]disagrees gets generated sources its ownforge fmtreflows"rainix-copy-artifactsregenerates, runsforge fmt, thengit diff --exit-code"line_length = 120andtab_width = 4"No link added here:
rainix-copy-artifacts.yamlis already linked once, at instance 1. Per #139, a reader who needs rainix's internals is sent to rainix in one link, once.Instance 3 — the six static gates (README:76-80)
rainix.yaml] is what runs all four in CI"rainix-sol.yaml"uses:line.solfile"rainix-sol-static.yaml, wrong the day rainix adds a seventh gate, drops one or renames onerainix-sol-static.yamlInstance 4 — publish (README:86-94)
package-release.yamltriggerPackage Release] calls rainix'srainix-autopublish.yamlreusable on every push tomain"soldeer-package: rain-sol-codegen"[package].versionto Soldeer"sol-v<x.y.z>"[package].versionto the next version"[package].versioninfoundry.tomlis therefore the next, unpublished version rather than the last published one"foundry.toml— what a reader editing it needs#139's "must survive" list, and where each now lives
line_length = 120andtab_width = 4, becauseLibCodeGenwraps againstMAX_LINE_LENGTH/NEWLINE_DUE_TO_MAX_LENGTHstated in[fmt]script/Build.sol[package].versionis the next, unpublished version; neither version nor tag set by handsoldeer-package: rain-sol-codegenexplicitlyrainix.yamlparagraphsrc/generated/andmeta/are test scratch, created on demand, committed empty-handedAlso untouched and still present: the
rainlanguage/rain.deployworked-example pointer and the statement that this repo carries no example of its own.Links made absolute
The README ships in the published soldeer package, where
.soldeerignorestrips.github/— so a repo-relative link into.github/workflows/resolves tonothing for the reader who actually has the package. That is the defect #95
recorded (measured against the published
0.1.11zip). Both relative links inthe rewritten clauses are now full
https://github.com/...URLs rather thanbeing carried over as-is:
.github/workflows/rainix.yaml.github/workflows/package-release.yamlLICENSES/LicenseRef-DCL-1.0.txtstays relative: that file does ship in thepackage, so the link resolves.
QA
so there is no assertion a test could carry. The claim under test is
"every sentence still corresponds to something true", which is checked by
reading the source of truth, below.
for a docs diff is that each retained claim was checked against the file that
owns it:
foundry.toml[fmt]really isline_length = 120/tab_width = 4; this repo'srainix.yamlreally doesuses: rainlanguage/rainix/.github/workflows/rainix-sol.yaml@main; thisrepo's
package-release.yamlreally ison: push: branches: [main]withsoldeer-package: rain-sol-codegen; rainix7f223b4'srainix-copy-artifacts.yamlreally does matchscript/Build.solexactly andhard-fail a committed
src/generated/without it, and itsrainix-autopublish.yamlreally does own the version bump and thesol-vtag. Every claim removed is one whose owning file is now linked instead.
plus the two upstream workflow files fetched from
raw.githubusercontent.com/rainlanguage/rainix/mainat HEAD7f223b4— readindependently of the README's account of them, which is the account under
suspicion.
third-party behaviour), illustrated by four instances. All four cut; the whole
file was then re-read for further instances and none remain — the surviving
third-party mentions are the nix/soldeer/rainix names this repo depends on
and its own
uses:values, not accounts of their behaviour.Verification
nix develop -c reuse lint— compliant, 47/47 files.nix develop -c forge fmt --check— clean.nix develop -c forge test— 147 passed, 0 failed.(
rainix-copy-artifacts.yaml,rainix-sol.yamltargetrainix-sol-static.yaml,rainix-autopublish.yaml), bothrain.sol.codegenworkflow files,rain.deployand itsscript/Build.sol, soldeer.xyz, nixos.org,opensource.org CAL-1.0, reuse.software 3.3.
LICENSES/LicenseRef-DCL-1.0.txtconfirmed present in the tree.
Only
README.mdchanges.