Over the previous a number of months, we’ve made important adjustments to Zebra’s steady integration and testing infrastructure. For these new to the mission, Zebra is the Zcash Basis’s full-node implementation written in Rust, offering an unbiased, memory-safe, and consensus-compatible various to zcashd.
These enhancements make it simpler for anybody to fork the repository, take a look at their adjustments, and contribute to the mission—with out counting on exterior companies or particular permissions.
Why These Adjustments Matter
Beforehand, contributing to Zebra meant coping with a number of roadblocks:
- Forked repositories couldn’t run most CI checks as a result of they trusted Firebase, exterior Docker registries, and different companies that contributors didn’t have entry to
- Take a look at builds have been gradual and typically rebuilt unnecessarily
- Complicated configuration made it onerous to know which checks have been operating and why
- Exterior dependencies added prices and made the CI fragile
We’ve systematically addressed every of those points.
What We’ve Improved
We’ve got made 5 notable enhancements:
1. CI Now Works on Forks
The largest change: when you fork Zebra, the CI simply works. We eliminated all dependencies on exterior companies that required particular entry:
- Documentation now deploys to GitHub Pages as a substitute of Firebase
- All workflows run on customary GitHub infrastructure
- Docker photographs construct instantly in GitHub Actions, now not requiring Google Cloud Platform or Docker Construct Cloud
- Eliminated 19 patch information and a couple of,900 strains of configuration complexity
We additionally made Zebra’s inside workflows simpler to establish by including a zfnd- prefix, so it’s clear which workflows are particular to the Zcash Basis’s infrastructure and which of them will work in your fork.
See our CI/CD structure documentation →
2. Quicker, Extra Dependable Exams with Nextest
We migrated Zebra’s complete take a look at suite to make use of cargo-nextest, a contemporary take a look at runner that provides a number of benefits:
- Quicker execution: Exams run in parallel with smarter scheduling
- Higher reliability: Correct timeout dealing with prevents false failures
- Clearer configuration: All 17 take a look at profiles are outlined in .config/nextest.toml as a substitute of scattered throughout shell scripts
- Easier workflows: One NEXTEST_PROFILE variable replaces dozens of surroundings flags
This alteration eradicated pointless rebuilds brought on by characteristic flag mismatches and streamlined how we run several types of checks (full sync, RPC checks, lightwalletd integration, and so forth.).
See our nextest profiles and take a look at classes →
3. Eliminated Exterior Construct Dependencies
We used to depend on exterior companies to construct Docker photographs as a result of the builds have been resource-intensive. This created two issues:
- Contributors couldn’t construct photographs of their forks
- It incurred in important prices
Now, Docker photographs construct totally inside GitHub Actions utilizing customary infrastructure. We made the builder configurable, so when you fork Zebra, your photographs will construct robotically with none particular setup.
The workflow additionally adapts to your surroundings—it makes use of customary GitHub runners in forks and bigger runners in the primary repository, so contributors aren’t blocked by runner dimension limitations.
Be taught extra about our Docker setup →
4. Streamlined Testing and Deployment
We simplified how checks are organized and run:
- Single unified workflow: As an alternative of constructing Docker photographs a number of instances throughout totally different workflows, we construct as soon as and reuse it for all checks.
- Constant naming: Standardized take a look at names throughout GitHub workflows, surroundings variables, and Rust code makes it simpler to hint failures and perceive what’s being examined.
- Simplified GCP integration: For checks that do run on Google Cloud Platform (in the primary repository), we eliminated the intermediate container layer and use direct occasion creation, which improves reliability and logging.
See our workflow group →5. Higher Configuration Administration
We changed the legacy configuration system with a contemporary layered method:
- Configure Zebra utilizing ZEBRA_ prefixed surroundings variables with no need a generated config file
- Simplified Docker entrypoint that doesn’t have to generate TOML information
- Clearer separation between defaults, elective TOML information, and surroundings overrides
This makes it simpler to check totally different configurations and reduces the complexity of the Docker entrypoint script.
See the configuration documentation →
What This Means for You
Whether or not you’re a contributor, a neighborhood member operating your individual Zebra node, or a company constructing on prime of Zebra:
- Fork and take a look at freely: You’ll be able to fork Zebra and run the total CI suite in your individual repository
- Quicker suggestions: Exams run quicker and extra reliably, so that you get faster suggestions on adjustments
- Simpler debugging: Clearer take a look at names and higher logging make it less complicated to know what went mistaken when a take a look at fails
- Decrease boundaries to entry: New contributors don’t want to know advanced exterior dependencies or request entry to particular companies
What’s Subsequent
We’re not executed but. The enhancements we’ve made thus far lay the groundwork for much more important adjustments coming quickly:
Smarter Take a look at Choice
We’re re-architecting how checks are organized and run so you possibly can select precisely what to check based mostly in your wants:
- Run by take a look at kind: Choose simply unit checks, integration checks, or stateful checks (checks that require a cached blockchain state)
- Run by high quality stage: Select between fast smoke checks and complete take a look at suites
- Run what issues: Should you’re engaged on RPC performance, run simply the RPC checks. Engaged on sync logic? Run solely sync-related checks.
This may make the event cycle quicker—you received’t want to attend for the whole take a look at suite if you’re solely altering a selected part.
Regtest for Quicker, Extra Dependable Testing
We’re contemplating a shift to utilizing regtest (regression take a look at mode—an area testing surroundings the place blocks may be generated on demand) as a substitute of counting on mainnet or testnet for advanced integration checks:
- No sync wait instances: Exams received’t want to attend for lengthy mainnet syncs to finish earlier than operating
- Predictable take a look at environments: Create customized blockchain states on demand slightly than relying on community state
- Quicker iteration: Run advanced community interactions with out the overhead of full blockchain synchronization
This alteration would make our stateful checks considerably quicker and extra dependable, particularly for testing advanced interactions between Zebra and the community.
Workflow Modernization
We’re persevering with to refactor our remaining specialised workflows, simplifying our infra-related deployment workflows
These adjustments will comply with the identical rules: scale back complexity, take away exterior dependencies the place doable, and make all the pieces work seamlessly in forks.
Steady Enchancment
The work we’ve accomplished over the previous few months demonstrates our dedication to creating Zebra simpler to work with. We’ll proceed to establish bottlenecks, simplify workflows, and enhance the contributor expertise.
Get Began!
All of those enhancements are already reside in the primary department. Should you’ve been interested by contributing to Zebra, or when you beforehand had hassle operating checks in your fork, now is a superb time to offer it one other strive.
To get began:
Questions or suggestions? We’d love to listen to about your expertise with the brand new CI setup. Tell us in Discord or open a difficulty within the Zebra repository.
The Zcash Basis is dedicated to transparency and openness with the Zcash neighborhood. We’ll proceed sharing updates on our engineering work and welcome your suggestions and contributions.
