Enabling cargo xtask

[Shourya742]

In SRI, CI and release management has been a long-standing pain point. The week leading up to a release is usually stressful: it’s easy to forget to bump a version, miss publishing a crate, or forget to push updated Docker images (even though we recently added a Docker setup). On top of that, every release still requires a manual deployment to our VPS. All of this manual intervention increases the risk of mistakes at each step. To reduce some of this friction, we open a tracking issue at the start of every release (for example: #2010) to make sure versions aren’t accidentally bumped multiple times during the release process.

Fortunately, this isn’t a problem unique to us, most large Rust repositories run into the same issues as their workflows grow. The de-facto standard that has emerged to address this is xtask: implementing project workflows directly in Rust instead of relying on ad-hoc shell scripts. Conceptually, it’s very similar to a traditional make-based setup: you define workflows once, and then invoke them with a single command. The difference is that, instead of make xyz, the entry point becomes cargo xtask xyz, with all the benefits of type safety, shared tooling, more powerful and first-class integration with the Rust ecosystem.

Let’s look at a few concrete scenarios where this would really help:

1. Bumping crate versions
   Instead of manually bumping versions in every PR that introduces a breaking change (or even a minor one), we can move this into an xtask flow. The task can run semver checks, review the output, and update versions across our main crates automatically. This alone would be a big win during release cycles ideally it becomes as simple as running cargo xtask bump all.

2. Publishing crates
   Today, publishing is a multi-step manual process: dry runs, checks, and then the actual publish. We can bundle all of that into a single routine, making releases far less error-prone and much less tedious.

3. Running CI locally
   We can expose CI routines via xtask so contributors can run the same checks locally and understand what’s failing before pushing. That makes debugging CI issues much easier and saves review cycles.

4. Pre-push checks
   We can add lightweight checks through cargo xtask that run before every push. In the past, pre-push hooks required contributors to set things up manually, which was easy to miss. This gives us similar guarantees without the hassle.

5. Publishing Docker images
   Now that we have a proper Docker setup in SRI, every release also needs updated images on Docker Hub. This can be folded directly into the publish routine and handled automatically via cargo xtask.

6. Deploying to the VPS
   Same idea here, release and deployment can go hand in hand. Instead of manual VPS deploys every time, we can have a dedicated routine that does this reliably and consistently.

7. Single entry point for tests
   We currently have multiple test suites unit tests, integration tests, fuzzing, benchmarks, and more. With xtask, we can streamline this into a single command, with flags to control what runs.

These are just some of the benefits I see with introducing xtask. This isn’t something I randomly came up with, it’s a pattern I’ve seen repeatedly in production-grade Rust projects.

A couple of good references:

• https://github.com/tracel-ai/xtask — a solid example that already covers many of the scenarios above and is a good starting point for understanding how we might integrate this into SRI.
• https://github.com/rust-lang/rust-analyzer — xtask is central to rust-analyzer’s local workflows and day-to-day development.

[plebhash]

just stumbled on this discussion and remembered about #2191

@Shourya742 is there some synergy here?

[plebhash]

btw I'm not arguing it is... just a high level thought that crossed my mind, but I don't know cargo xtask well enough

maybe it's a brainfart, ignore if that's the case

[Shourya742]

xtask is rust way of makeFile, we still have to implement our semver requirements.