magicblock-labs / magicblock-labs/magicblock-validator

Remove the test-integration workspace after RedSuite 1.0.0

Open
#1,646 0 comments 0 reactions 1 assignee View on GitHub

@bzawisto is already working on this.

Since Sep 4, 2026.

breaking-change techdebt
Dominant language
Rust
Stars
58
Forks
58
Avg merge
22h 1m
Merged PRs (30d)
53

Description

## Outcome

Remove the standalone `test-integration` Cargo workspace after RedSuite 1.0.0 becomes the authoritative black-box validator qualification suite.

The removal must reduce duplicate test infrastructure without reducing release confidence. A `1.0.0` tag alone is not sufficient: RedSuite must demonstrate dense coverage of the behavior still protected by `test-integration` and pass against the exact MBV revision from which the workspace will be removed.

This is the final cleanup anticipated by [#1360](https://github.com/magicblock-labs/magicblock-validator/issues/1360), not another test migration project.

## Scope

Before removal:

- Publish an official [RedSuite](https://github.com/magicblock-labs/redsuite) `1.0.0` release.
- Complete the validator qualification work tracked by [RedSuite #66](https://github.com/magicblock-labs/redsuite/issues/66), HTTP RPC coverage tracked by [#82](https://github.com/magicblock-labs/redsuite/issues/82), and their required children.
- Produce a behavior-level disposition of the legacy workspace: every test must map to a RedSuite scenario, a focused test in the owning MBV crate, or an explicitly reviewed obsolete/redundant case. Do not mechanically port white-box tests into RedSuite.
- Move still-required internal invariants into focused tests owned by the relevant production crate. Delete redundant and obsolete cases.
- Run the RedSuite 1.0 release qualification profiles against the exact target MBV revision and retain the scenario reports and revisions as removal evidence. The run must have no correctness failures, crashes, unrecovered lifecycle failures, or unexplained scenario skips.

After the gate is satisfied:

- Delete the complete `test-integration/` workspace, including its manifests, lockfile, runner, fixtures, programs, configs, and test crates.
- Delete `.github/workflows/ci-test-integration.yml` and integration-only artifact, cache, and SBF build plumbing.
- Remove the `ci-test-integration`, integration format, and integration lint targets from the root `Makefile`.
- Remove integration-workspace build and locked-metadata steps from the release-preparation workflow.
- Remove all remaining build, CI, and release references whose only purpose was supporting `test-integration`.
- Keep the main workspace's unit and crate-level integration tests intact; RedSuite does not replace tests that need direct access to internal APIs.
- Queue a separate documentation-only cleanup for stale repository guidance, including removal of `.agents/skills/mbv-run-single-integration-test`; do not mix that documentation change into the code-removal pull request.

Do not maintain a dormant copy of the workspace or a second compatibility runner after cutover. Git history is the archive.

## Acceptance criteria

- [ ] RedSuite `1.0.0` is published as an official GitHub Release.
- [ ] RedSuite #66 and #82 and their required children are closed.
- [ ] Every legacy test has a reviewed disposition: RedSuite scenario, owning-crate test, or accepted removal.
- [ ] Required internal-only guarantees have focused coverage in their owning crates before deletion.
- [ ] RedSuite 1.0 release qualification passes against the exact target MBV revision, with reports and both repository revisions linked from this issue or its pull request.
- [ ] `test-integration/` and its dedicated CI, runner, fixtures, programs, configuration, cache, and release plumbing are removed.
- [ ] The main workspace format, Clippy, and test gates pass without relying on the removed workspace.
- [ ] No build, CI, or release path references `test-integration` after removal.
- [ ] A separate documentation-only cleanup is linked for stale `.agents` and contributor guidance.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.