Runs on a composition

knotless-run --executor composition runs a repository’s checks on the atlibs composition its owner binds, in process: the composition rents a machine, its workload runs the steps, and it gives the machine back (design).

Bind a repository

A com.fedfork.exec.binding record in your account, at the repository’s key, or self for all of them: the composition pinned by CID, and its parameters.

{
  "$type": "com.fedfork.exec.binding",
  "composition": { "uri": "at://did:plc:ocnuqjlzgohypj3zoznermms/com.fedfork.exec.composition/socialweb-computer-cicd", "cid": "bafyrei…" },
  "inputs": { "bidders": ["did:plc:4vcig7s43z3nyqrnepmcfzqt"] },
  "createdAt": "2026-11-10T00:00:00Z"
}

atlibs publish records records/self.json --as you.bsky.social

Then sign in once at the runner for that composition, granting only its modules’ scopes: https://<runner>/oauth/composition/<cid>/login?handle=<you>&composition=<at:// URI>.

Run one

knotless-run --executor composition \
  --trust-publisher did:plc:ocnuqjlzgohypj3zoznermms \
  --origin https://runner.example --listen 127.0.0.1:8796 \
  alice.example/project

A run: the binding (getRecord at the repository’s key, then self) → the composition at its CID, its publisher’s and every module’s trusted → its parameters → computer.socialweb.vm.prepare (once per owner) → computer.socialweb.vm.provision → computer.socialweb.cicd.workload.run, the checkout, then a step a call → computer.socialweb.vm.release, always.

Not yet: pulls and the merge queue (their merged commit is on no remote), shared steps, outputs, caches.