Priority: Medium · Area: Build tooling consistency · Est. effort: 5–8 h
📌 Problem
The repository defines its build steps twice.
Makefile targets: build, test, fmt, fmt-check, wasm, clean.
.github/workflows/ci.yml steps: cargo fmt --all -- --check, cargo build, cargo test — invoking cargo directly rather than the Makefile.
Two independent definitions of the same operations drift. The clearest evidence is already present: CI never invokes wasm:, so the contract is never built for its deployment target (tracked separately as its own issue). A contributor running make locally and a maintainer reading ci.yml are looking at different pipelines, and neither is authoritative.
Concretely: if someone improves make build — adds a flag, a feature, a target — CI does not benefit, and the local build stops matching the verified one.
🎯 Design decision required
State and defend:
- Single source of truth. Should CI call
make, or should the Makefile be removed in favour of cargo invocations documented in the README? Both are defensible. What is not defensible is keeping two definitions that can silently diverge. Argue one.
- Coverage. Whichever you choose, every operation a contributor needs — build, test, fmt, wasm, clippy once added — must be reachable the same way locally and in CI. List them and confirm parity.
- Interaction with the wasm issue. Wiring the wasm build into CI is tracked separately. Say which PR lands that step, and make sure your change does not conflict.
🧩 Requirements and context
- After the change there must be exactly one definition of each operation.
- The README must document how to run each operation locally, matching what CI does.
- Do not change what any operation actually does in this PR — this is about removing duplication, not altering behaviour.
- If CI calls
make, confirm make is available on the runner and that failures propagate correctly (a Makefile recipe that swallows a non-zero exit is a real hazard — check for it).
rust-toolchain.toml pins the toolchain; both paths must respect it.
🛠️ Suggested execution
- Tabulate every operation, how the Makefile does it, and how CI does it. Report any difference — differences found are the substance of this issue.
- Choose the single source of truth and implement.
- Verify each operation behaves identically to before.
- Confirm a failing step fails the CI job.
- Update the README.
✅ Acceptance criteria
🚫 Out of scope
- Adding the wasm build to CI — separate issue, though coordinate on ordering.
- Adding clippy — separate issue.
- Changing what any build step does.
🧪 Verification
make fmt-check
make build
make test
make wasm
cargo test
📤 What your PR must include
- The operation comparison table and every divergence found.
- Your single-source-of-truth decision and its reasoning.
- Confirmation of local/CI parity per operation.
- A link to a run proving failures propagate.
Closes #<n>.
🔒 Security notes
Divergent build definitions mean the artefact a contributor tests is not necessarily the artefact CI verifies. For a contract compiled to wasm and deployed on-chain, that gap matters: a flag present in one path and absent in the other — optimisation level, feature selection, target — can produce a materially different binary from the one anyone reviewed.
📋 Guidelines
- Minimum 95% test coverage on changed lines
- Clear documentation
- Timeframe: 96 hours from assignment
- One logical change per commit; no merge commits
💬 Join our community
Working on this, or want to sanity-check your approach before you start? Come and ask — the maintainers are there and happy to help.
Telegram: https://t.me/Grainlify
Priority: Medium · Area: Build tooling consistency · Est. effort: 5–8 h
📌 Problem
The repository defines its build steps twice.
Makefiletargets:build,test,fmt,fmt-check,wasm,clean..github/workflows/ci.ymlsteps:cargo fmt --all -- --check,cargo build,cargo test— invoking cargo directly rather than the Makefile.Two independent definitions of the same operations drift. The clearest evidence is already present: CI never invokes
wasm:, so the contract is never built for its deployment target (tracked separately as its own issue). A contributor runningmakelocally and a maintainer readingci.ymlare looking at different pipelines, and neither is authoritative.Concretely: if someone improves
make build— adds a flag, a feature, a target — CI does not benefit, and the local build stops matching the verified one.🎯 Design decision required
State and defend:
make, or should theMakefilebe removed in favour of cargo invocations documented in the README? Both are defensible. What is not defensible is keeping two definitions that can silently diverge. Argue one.🧩 Requirements and context
make, confirmmakeis available on the runner and that failures propagate correctly (a Makefile recipe that swallows a non-zero exit is a real hazard — check for it).rust-toolchain.tomlpins the toolchain; both paths must respect it.🛠️ Suggested execution
✅ Acceptance criteria
cargo testpasses.🚫 Out of scope
🧪 Verification
📤 What your PR must include
Closes #<n>.🔒 Security notes
Divergent build definitions mean the artefact a contributor tests is not necessarily the artefact CI verifies. For a contract compiled to wasm and deployed on-chain, that gap matters: a flag present in one path and absent in the other — optimisation level, feature selection, target — can produce a materially different binary from the one anyone reviewed.
📋 Guidelines
💬 Join our community
Working on this, or want to sanity-check your approach before you start? Come and ask — the maintainers are there and happy to help.
Telegram: https://t.me/Grainlify