cd /news/developer-tools/i-shipped-my-first-rust-release-and-… Β· home β€Ί topics β€Ί developer-tools β€Ί article
[ARTICLE Β· art-67731] src=dev.to β†— pub= topic=developer-tools verified=true sentiment=Β· neutral

I Shipped My First Rust Release, and CI Turned Red Twice in 20 Minutes

A developer shipped the first public release of AgentOS, a Rust runtime layer for AI agents, and encountered two CI failures within 20 minutes. The first was a clippy lint fix, and the second involved a cross-compilation issue with OpenSSL on Linux arm64, which was temporarily resolved by dropping that target from the release matrix.

read4 min views1 publishedJul 21, 2026

I shipped the first public release of my Rust project last night. Within about twenty minutes, CI turned red twice. Here's what broke, how I found it, and the two calls I made under a bit of time pressure.

AgentOS is a runtime layer for AI agents β€” the infrastructure around an agent, not the agent logic itself: supervised lifecycle, a gRPC message bus, a health endpoint, an SSE event stream, a secrets vault, and deterministic time-travel replay (every LLM/tool exchange gets journaled, so a run can be replayed offline with no API cost, and forked into alternate timelines from any checkpoint).

It's a 10-crate Rust workspace, MIT/Apache-2.0. I'd been building it privately for a while. Last night I flipped the repo to public and tagged the first alpha release. That's when things got interesting.

The repo had been private, so CI hadn't run against a fresh clippy

in a while. The moment I pushed a commit after going public, this showed up:

error: you seem to want to iterate on a map's values
   --> crates/bus/src/grpc.rs:631:37
    |
631 |         for (_agent_id, senders) in subs.iter() {
    |                                     ^^^^^^^^^^^
    |
    = help: use the corresponding method
631 -         for (_agent_id, senders) in subs.iter() {
631 +         for senders in subs.values() {

clippy::for_kv_map

, denied by -D warnings

in CI. Fair catch β€” the code was iterating a HashMap

and discarding the key on every iteration, which is exactly what .values()

is for. One-line fix:

// before
for (_agent_id, senders) in subs.iter() {

// after
for senders in subs.values() {

Pushed, CI green again. This one was boring, which is the best kind of bug to have.

The bigger one showed up when I tagged v0.1.0-alpha

. The release workflow builds five targets in parallel β€” Linux x64, Linux arm64, macOS Intel, macOS Apple Silicon, Windows β€” and packages each into a binary release with checksums.

Four went green. Linux arm64 died with:

error: failed to run custom build command for `openssl-sys v0.9.116`
...
Could not find directory of OpenSSL installation
$HOST = x86_64-unknown-linux-gnu
$TARGET = aarch64-unknown-linux-gnu

openssl-sys

needs a real OpenSSL installation (headers + libs) for the target architecture to link against, and cross-compiling from an x86_64 GitHub Actions runner to arm64 doesn't have that available without extra setup. Not a code bug β€” a missing piece of cross-compilation infrastructure.

I had three honest options at that point:

I went with option 3. Four platforms is still a real alpha release that covers the overwhelming majority of contributors trying it out. Blocking on a cross-compilation edge case for a Linux architecture almost nobody in the alpha audience runs felt like optimizing for the wrong thing at midnight. And silently vendoring a rushed fix into a security-relevant dependency (TLS) is exactly the kind of shortcut that comes back to bite you.

So: pulled the target from the matrix, re-tagged, watched the four remaining builds go green, and filed the real fix as its own issue with three candidate approaches laid out (the best one is probably migrating off openssl-sys

to rustls

entirely, which would remove the system OpenSSL dependency for every target, not just arm64 β€” cross-compilation problems like this are usually a sign the dependency choice needs revisiting, not just the CI config).

Before any of the above, I'd actually run the README's own quickstart end to end β€” cargo build --workspace

, then run the example agent β€” specifically to catch the gap between "the README claims this works" and "this actually works." It did, and the real terminal output (supervisor spawning the agent, health server on :8080

, gRPC bus on :50051

, an SSE stream on :8081

) is now in the README instead of a hypothetical example. I also downloaded the actual released Windows binary afterward and ran agentOS.exe --version

against it β€” small thing, but it's the difference between "the release workflow exited 0" and "a stranger who downloads this file gets a working program."

Neither bug was catastrophic. Both were the kind of thing that's mildly stressful in the moment and completely mundane in hindsight β€” which is most of what real engineering work actually looks like, release-day war stories included.

If you want to poke at it, the repo's here: ** github.com/WAHIB-EL-KHADIRI/AgentOS**. There are a handful of labeled

good first issue

s if anyone wants to dig into a self-contained piece of it β€” I'm around to answer questions on any of them.

── more in #developer-tools 4 stories Β· sorted by recency
── more on @agentos 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain β€” perfect for shipping the agent you just read about.

$git push zahid main
β†’ Live at https://your-agent.zahid.host βœ“
Get free account β†’ Pricing
from €0/mo Β· no card required
LIVE [news/i-shipped-my-first-r…] indexed:0 read:4min 2026-07-21 Β· β€”