Infrastructure

Everything shapekit's deliverables run on, what they talk to, and what they record about their users (nothing). Versions are the ones pinned in pins.toml; shapekit pins verify checks every pin against its upstream source and upstream-drift.yml re-checks them weekly.

Where it runsCopy Anchor Link

All CI runs on GitHub-hosted ubuntu-24.04 runners. There are no self-hosted runners, servers, databases, hosted services or other build systems. Releases are GitHub releases of this repository. Nothing runs between CI jobs.

Users run the tools on their own machines or CI runners. The tools need Linux on x86-64 (the released binaries), and Docker for the commands that start containers (gen, harness, the check-lcm script).

ToolchainsCopy Anchor Link

Stellar stackCopy Anchor Link

Each of these was the newest stable upstream release on 2026-11-13 (checked with git ls-remote, crates.io, npm and the Go module proxy; scripts/upstream-releases.sh --dry-run reports no drift). The stellar CLI (stellar-cli 30.0.1) is not used by any deliverable and is not pinned.

The full lists (every crate, npm package and Go module with its purpose) are in pins.toml.

Container imagesCopy Anchor Link

All pulled by digest, never by tag; scripts/pin.sh image <name> prints the reference.

The adapter also builds shapekit-wallet-backend:<commit> from wallet-backend's own Dockerfile at the requested commit. That Dockerfile names its base images by tag; the adapter replaces each FROM with the digest pinned here, through docker buildx build --build-context <tag>=docker-image://<repository>@<digest>, and refuses to build a commit whose Dockerfile names a base it has no pin for (BaseImages in adapters/walletbackend/docker.go, checked against pins.toml by its tests):

The packages the Dockerfile installs with apt-get and go install are not pinned by this repository; they come from wallet-backend's Dockerfile as it is. pr.yml and the nightly harness cache the adapter's clone and the built image (docker save) with actions/cache, keyed by the wallet-backend commit and the base image digests, so a run with a cache hit builds nothing and fetches nothing for wallet-backend.

Containers are isolated from the network: the core driver runs stellar-core on a Docker network created with --internal and refuses to start otherwise, with all capabilities dropped; the harness creates an --internal network for the target and binds the replay server to that network's gateway address.

CICopy Anchor Link

Permissions: contents: read everywhere, except issues: write for the drift workflow (its tracking issues) and, in the release job only, contents: write, id-token: write, attestations: write and artifact-metadata: write (publishing and attestations). The only token used is the built-in GITHUB_TOKEN. No other secrets exist.

Measured durationsCopy Anchor Link

The budget is 15 minutes of wall clock per pull request on standard hosted runners (4 vCPUs). These numbers were measured on 2026-11-12 on the development machine, not yet on GitHub: a 10-core x86-64 box shared with other work (load average 8 to 11 during the runs), with builds limited to 2 parallel jobs (CARGO_BUILD_JOBS=2, GOFLAGS=-p=2, verify-repro --jobs 2) and a fresh cargo target directory, so they are the cold-cache case. The Go and npm download caches were warm. They will be replaced by the durations of the first three green runs on GitHub.

The corpus has grown since these runs. It now holds 32 recipe families, 43 chains and 86 recordings (one per chain and network; shapekit pack verify reports "86 chains checked"), so the full verify-repro and the nightly harness rows understate today's work by about the ratio of the chain counts (43 to 38, and 43 to 33). The rows say which corpus size they were measured on.

Not measured locally: runner start, artifact upload and download, and docker pull of the core image (789 MB) and the timescaledb image (1.85 GB) on a hosted runner.

The longest dependency chain of pr.yml is the release build followed by the slowest verify-repro shard: about 10 minutes cold and about 6 minutes with the cargo cache, plus image pulls. Every job has a timeout of 15 minutes or less, so a run that would exceed the budget fails instead of passing slowly. Nothing was dropped from the per-PR tier to meet the budget; the split into parallel jobs and the verify-repro shards is what keeps the wall clock under it.

Network access and telemetryCopy Anchor Link

shapekit collects no telemetry. It does not phone home, report usage, check for updates, or send crash reports, and no workflow uploads anything about who runs the tools.

These are the only commands that use the network, each only when run explicitly:

Everything else (gen, manifest, registry, synth, oracle, goldens, coverage, guide, pack, corpus pack, serve, harness run once images exist, indexerlint) runs offline. gen never pulls the core image; it fails with the docker pull command to run when the image is missing. shapekit serve listens on 127.0.0.1:8000 unless told otherwise and serves only the chain it was given.

Maintenance scripts, which are not part of the tools users run: scripts/upstream-releases.sh and scripts/golden-drift.sh read public release and tag information from GitHub, npm, crates.io and the Go module proxy, and fetch core's golden index files; the drift workflow runs them. nightly.yml and release.yml clone stellar-core at the pinned tag for the goldens.