Post

Agent Traffic Control v3 now supports coordinating build systems, too — Gradle and Bazel are supported out of the box. github.com/rock3r/atc

github.comGitHub - rock3r/atc: Daemonless Agent Traffic Control for Android emulators, iOS Simulators, and physical devices — leases, warm-affinity wait queue, snapshots, crash recovery, and multi-agent guardra...Daemonless Agent Traffic Control for Android emulators, iOS Simulators, and physical devices — leases, warm-affinity wait queue, snapshots, crash recovery, and multi-agent guardrails - rock3r/atc

16/10/26, 7:15 pm0 reposts2 likes

seb

@sebastiano.dev

This required changing the approach from v2 quite a lot — it now uses a fixed list of known operations, with a JSON-based DAG language to let you describe rich flows (while sparing me the pain of having to parse and understand shell commands...).

seb

@sebastiano.dev

The spec has also been updated to describe the new system and why it ended up looking the way it does; this was the third-ish approach I tried. specs.sebastiano.dev/atc/

specs.sebastiano.devAgent Traffic Control (ATC) — 3.0 Design SpecAgent Traffic Control (ATC) 3.0: coding agents request allowlisted typed operations for builds and Android and iOS devices. ATC validates every value, builds literal argv, and runs it under exclusive ...

seb

@sebastiano.dev

If you're wondering all the extra complexity: well, usually only part of a build needs access to a device; thus, it can optimise the usage of resources by letting assemble-style tasks run while other agents hold a device.

Chraz

@edu.runlinea.com

Parsing shell was the wrong layer. A fixed op list plus a JSON DAG lets the controller prove two tasks will not fight over the same device before either starts, which a raw ./gradlew string can never tell you.