run Sorus from CI

Run a Cargo check or test on Sorus while your existing CI handles checkout, packaging and deployment. This guide assumes you can edit that CI workflow and manage its secrets. For the underlying concepts, read Rust CI basics.

Before starting, obtain beta access, authorise the repository and confirm the workload scope. Use the client installation instructions supplied for your release.

run a CI job

1. Select a supported Cargo step and keep the existing version available for comparison and fallback.
2. Install the approved client on the CI runner and check out the authorised repository.
3. Supply a scoped credential using the CI system’s protected secret mechanism. See authentication.
4. Add the matching Sorus command as a shell step. For a workspace that uses a lockfile, examples are:

cargo sorus check --workspace --locked
cargo sorus test --workspace --locked

Use the command that matches your existing step. Retain the same features, profile and other Cargo arguments. Use --locked only when it matches the repository’s lockfile policy.

GitHub Actions and other CI systems

In GitHub Actions, inject SORUS_TOKEN from an Actions secret into the client step. Other CI systems can use their own protected secret mechanism; the Sorus command is the same.

Establish fork permissions before enabling automatic execution. Do not expose a privileged token to untrusted pull-request code.

report a GitHub check

To report on a commit, add --check-commit <sha> to the Cargo invocation. This publishes a check named sorus through your account’s GitHub installation.

Confirm that the commit and repository are authorised and that the installation has the required permissions. Verify the reported result during your evaluation. Actions-independent orchestration and automatic fallback are still in design.

handle failures

Keep the job identifier and distinguish exit 1 (workload outcome), 4 (no outcome observed) and 5 (terminal platform failure). Inspect the job before retrying.

Apply your team’s fallback policy for platform failures; do not report them as passing checks or failed tests. See job recovery for the complete exit-code decision table. Check the recorded cancellation source when an upstream workflow is cancelled: it differs from a terminal client detaching with Ctrl-C.

require a check

Compare Sorus with your existing CI before making its result required. Use the same source, arguments and expected outcomes; record differences. Retain a working fallback until your team accepts the operational results. For performance comparisons, follow the benchmark method.