2026-09-08 13:11:03 +00:00
2026-09-08 13:11:03 +00:00
2026-02-09 09:32:20 +00:00
2026-09-08 13:11:03 +00:00
2026-02-09 09:32:20 +00:00
2026-02-09 09:32:20 +00:00
2026-02-09 09:32:20 +00:00
2026-02-09 09:32:20 +00:00
2026-09-08 13:11:03 +00:00
2026-02-09 09:32:20 +00:00

@git.zone/tsrust

A CLI build tool for Rust projects that follows the same conventions as @git.zone/tsbuild. It detects your rust/ source directory, parses Cargo.toml (including workspaces), runs cargo build --release with a managed target cache, and copies the resulting binaries into a clean dist_rust/ directory at the project root.

Issue Reporting and Security

For reporting bugs, issues, or security vulnerabilities, please visit community.foss.global/. This is the central community hub for all issue reporting. Developers who sign and comply with our contribution agreement and go through identification can also get a code.foss.global/ account to submit Pull Requests directly.

Install

Install globally with pnpm:

pnpm add -g @git.zone/tsrust

Or as a project-level dev dependency:

pnpm add --save-dev @git.zone/tsrust

No Rust required! If cargo isn't found on your system, tsrust automatically downloads and installs a minimal Rust toolchain to /tmp/tsrust_toolchain/. This gives a zero-setup experience. If you already have Rust installed, tsrust uses your system toolchain.

The Convention

tsrust mirrors the directory convention established by tsbuild:

Tool Source Directory Output Directory
tsbuild ts/ dist_ts/
tsrust rust/ dist_rust/

Your Rust code lives in rust/ (or ts_rust/ as fallback), and compiled binaries land in dist_rust/ — ready for packaging, deployment, or further tooling.

Usage

🔨 Build (Default Command)

Simply run tsrust from your project root:

tsrust

This will:

  1. Detect the Rust toolchain (system cargo, or auto-install to /tmp/tsrust_toolchain/)
  2. Locate your rust/ directory (containing Cargo.toml)
  3. Parse the workspace to discover all [[bin]] targets
  4. Run cargo build --release with full streaming output
  5. Store Cargo intermediates in .nogit/tsrust-target by default
  6. Copy each binary to dist_rust/ with executable permissions (chmod 755)
  7. Write a SHA-256-bound provenance sidecar without changing the binary bytes
  8. Report file sizes and total build time

Example output:

Using cargo 1.90.0 (840b83a10 2025-07-30)
Found Rust project at: rust
Detected Cargo workspace
Binary targets: rustproxy
Running: CARGO_TARGET_DIR="/path/to/project/.nogit/tsrust-target" cargo build --release
   Compiling rustproxy v0.1.0
    Finished `release` profile [optimized] target(s) in 29.01s
Copied rustproxy (13.4 MB) -> dist_rust/rustproxy
Wrote provenance: @example/rustproxy@1.0.0 abc123def456 (native)
Done in 29.2s

Automatic Rust Toolchain

tsrust provides a zero-setup experience through automatic toolchain management:

  1. System toolchain detected → uses it as-is (no download, no overhead)
  2. No system toolchain → checks /tmp/tsrust_toolchain/ for a previously installed bundled toolchain
  3. No ready bundled toolchain → installs a minimal host-qualified stable toolchain with rustup-init, or cleanly reinstalls a secure but incomplete managed toolchain

The bundled toolchain is stored in /tmp/, so it's cleaned up on reboot. Subsequent runs reuse the existing installation. Before executing it, tsrust requires the root to be a current-user-owned, non-symlink directory, restricts it to mode 0700, verifies that cargo and rustup resolve to current-user-owned executables inside that root that are not group- or world-writable, and binds cargo, rustc, and target-manifest checks to the exact managed stable toolchain for the execution host. A securely resolved installation that fails readiness is removed and freshly installed through rustup under the installation lock. An atomically published current-user-owned installation lock serializes validation and bootstrap. A dead installer fails closed with the exact lock path for operator inspection instead of risking concurrent stale-lock deletion.

Supported platforms for automatic install: Linux (x64, arm64) and macOS (x64, arm64).

🐛 Debug Build

Build with the debug profile instead of release:

tsrust --debug

Binaries are taken from .nogit/tsrust-target/debug/ instead of .nogit/tsrust-target/release/.

🧹 Clean Before Building

Run cargo clean before building to force a full rebuild:

tsrust --clean

Cross-Compilation

Cross-compile for different OS/architecture combinations using the --target flag:

# Cross-compile for a single target
tsrust --target linux_arm64

# Cross-compile for multiple targets
tsrust --target linux_arm64 --target linux_amd64

# Full Rust triples are also accepted
tsrust --target aarch64-unknown-linux-gnu

Supported friendly target names:

Friendly name Rust target triple
linux_amd64 x86_64-unknown-linux-gnu
linux_arm64 aarch64-unknown-linux-gnu
linux_amd64_musl x86_64-unknown-linux-musl
linux_arm64_musl aarch64-unknown-linux-musl
macos_amd64 x86_64-apple-darwin
macos_arm64 aarch64-apple-darwin

When using --target, output binaries are named <binname>_<os>_<arch>:

dist_rust/
├── rustproxy_linux_arm64
├── rustproxy_linux_arm64.tsrust-build.json
├── rustproxy_linux_amd64
└── rustproxy_linux_amd64.tsrust-build.json

tsrust automatically installs missing rustup targets via rustup target add when needed.

Configuration via .smartconfig.json

You can set default cross-compilation targets in your project's .smartconfig.json file so you don't need to pass --target flags every time:

{
  "@git.zone/tsrust": {
    "targets": ["linux_arm64", "linux_amd64"],
    "locked": true,
    "targetDir": ".nogit/tsrust-target",
    "pruneAfterBuild": false
  }
}

When targets are configured in .smartconfig.json, simply running tsrust will cross-compile for all listed targets. CLI --target flags determine the selected targets when provided. The complete configuration is still validated first, so malformed legacy or host-specific entries are always rejected.

For builds split across Linux and macOS hosts, select targets by build host:

{
  "@git.zone/tsrust": {
    "targetsByHost": {
      "linux": ["linux_amd64", "linux_arm64"],
      "macos": ["macos_amd64", "macos_arm64"]
    },
    "locked": true
  }
}

Host selection uses this precedence: CLI --target, exact host key, OS-family key, legacy targets, then a native build. Exact host keys are linux_amd64, linux_arm64, macos_amd64, and macos_arm64; OS-family keys are linux and macos. The selected entries are not merged, so an exact host entry completely replaces its family entry for that host.

locked: true runs Cargo builds with --locked for deterministic dependency resolution. This requires Cargo.lock to exist and remain consistent with the manifests; Cargo fails instead of updating an inconsistent lockfile.

targetDir is optional. It must point to a tsrust-owned path under .nogit/, such as .nogit/tsrust-target or .nogit/tsrust-custom-target. You can also set TSRUST_TARGET_DIR for one-off runs. pruneAfterBuild: true or TSRUST_PRUNE_AFTER_BUILD=true removes the marked managed target cache after binaries have been copied to dist_rust/.

Build Provenance

Every new build writes <binary>.tsrust-build.json beside the binary. In a Git checkout, the sidecar records the consuming package name and version, exact commit and dirty state, target, build time, and tsrust version. Non-Git builds record gitCommit: "unknown" and omit gitDirty. The sidecar also contains the binary's SHA-256 digest, so provenance reads fail if either file no longer belongs to the pair. The binary itself remains byte-identical to the postprocessed Cargo target-cache binary, preserving Mach-O signatures and other binary-format integrity checks. On Darwin targets, tsrust preserves an existing valid signature and applies an ad-hoc signature only when codesign explicitly identifies the Cargo output as unsigned. Invalid or ambiguous signature states fail the build. Signing happens before the binary is copied and before its provenance digest is written.

Inspect a built artifact with:

tsrust inspect dist_rust/rustproxy_linux_amd64

inspect verifies and reads the sidecar. It retains read compatibility with provenance trailers produced by tsrust 1.7 and 1.8, but new builds no longer append those trailers.

tsrust snapshots the Git commit and complete worktree status before each Cargo build and verifies that neither changed before copying artifacts. Dirty builds remain possible for development and are marked as dirty; strict multi-host assembly rejects them.

Multi-Host Assembly

Each host build owns and cleans its own dist_rust/. Copy those host outputs into separate artifact directories, then assemble the complete matrix from the same clean Git checkout and package version:

tsrust assemble .nogit/artifacts/linux .nogit/artifacts/macos

The union of targets and targetsByHost defines the required target matrix. Repeated --target options can define an explicit matrix instead. Assembly always publishes to the tsrust-owned dist_rust/ directory.

Assembly requires every Cargo binary for every expected target. It rejects missing, duplicate, unexpected, non-executable, symlinked, hash-mismatched, dirty, wrong-commit, wrong-package, and wrong-tsrust-version inputs. Validation and copying happen in a same-filesystem transaction under .nogit/tsrust-assembly/, guarded by the atomically published .nogit/tsrust-assembly.lock. The Git commit, clean worktree, and package identity are checked again immediately before publication. The previous output is retained until the complete staged matrix is ready, and successful publication removes files left by older matrices.

The transaction records a boot-scoped host identity, process, owner token, publication phase, and exact digest manifest for staged binaries and sidecars. A separate atomic recovery claim serializes dead-owner recovery. When the owner lock and state are readable and consistent, a later invocation on the owning host rejects a live process, rolls back an interrupted pre-commit publication after that process exits, and completes publication or cleanup after durable commit intent only after revalidating the manifest. Legacy committed v1 transactions from tsrust 1.9 are validated against the current exact assembly request, upgraded with a manifest, and then completed; incompatible legacy staging fails closed. A confirmed missing state file is safe to clean because the owner-lock protocol forbids output mutation before initial state persistence; malformed, non-regular, unreadable, owner-inconsistent, or manifest-inconsistent state fails closed. A transaction owned by another host is never taken over automatically because portable filesystem operations cannot fence a paused remote writer. If committed cleanup cannot finish immediately, the programmatic result reports cleanupPending: true and the CLI prints a warning; the owning process can retry it immediately.

Native Build Matrix

tsrust matrix automates host-partitioned builds and strict assembly. Committed configuration identifies expected worker architectures and names the environment variables that contain operator-local SSH details:

{
  "@git.zone/tsrust": {
    "targetsByHost": {
      "linux": ["linux_amd64", "linux_arm64"],
      "macos": ["macos_amd64", "macos_arm64"]
    },
    "locked": true,
    "matrix": {
      "builders": {
        "linux_amd64": {
          "transport": "local"
        },
        "macos_arm64": {
          "transport": "ssh",
          "destinationEnv": "TSRUST_MACOS_SSH",
          "temporaryRootEnv": "TSRUST_MACOS_TEMP_ROOT"
        }
      },
      "smokeTestArgs": ["--version"],
      "verificationCommand": ["cargo", "test", "--manifest-path", "rust/Cargo.toml", "--workspace", "--locked"],
      "forwardEnvironment": ["NPM_TOKEN"]
    }
  }
}

matrix.verificationCommand is optional. It is an executable followed by literal arguments, with no shell expansion. It runs once per configured worker in that worker's exact-commit checkout, after frozen dependency installation and before the artifact build. Use ['pnpm', 'run', 'verify-native'] for a reviewed project script that combines Rust and public API qualification. A test failure, timeout, interruption or tracked-source mutation prevents artifact assembly and preserves the prior output. Verification inherits the restricted worker environment, pnpm age policy, shared one-hour worker deadline and owned process-group cleanup; SSH workers also retain the disconnect watchdog. Arguments are limited to 256 entries and 64 KiB total, with no NUL or line breaks. Keep credentials out of committed commands and test output.

Successful NativeMatrixBuilder.build() results include verifiedWorkers, the host keys on which verification completed; it is empty when no command was configured. matrix check checks capabilities only and does not run verification.

Set the referenced values outside the repository. The SSH destination may be an OpenSSH alias or user@host; the temporary root must be a dedicated absolute path owned by the remote account:

export TSRUST_MACOS_SSH="release-user@mac-builder.example"
export TSRUST_MACOS_TEMP_ROOT="/Users/release-user/.git.zone/tsrust/my-project"
export TSRUST_MATRIX_ALLOWED_ENVIRONMENT="NPM_TOKEN"

Builder keys are limited to linux_amd64, linux_arm64, macos_amd64, and macos_arm64. At most one worker may use transport: "local". Worker target partitions must be non-empty, disjoint, complete, and from the worker's OS family. Matrix execution probes support the six predefined targets linux_amd64, linux_arm64, linux_amd64_musl, linux_arm64_musl, macos_amd64, and macos_arm64. Native GNU targets require cc; non-native GNU probes use their predefined *-linux-gnu-gcc command. Musl probes always use their predefined *-linux-musl-gcc command. Non-native architectures also require executable emulation.

Environment-variable names must match [A-Za-z_][A-Za-z0-9_]*. Committed forwardEnvironment entries are requests, not grants: every requested name must also appear in the operator-owned comma-separated TSRUST_MATRIX_ALLOWED_ENVIRONMENT value or matrix construction fails. Built-in worker and transport names cannot be requested, including PATH, HOME, CI, RUSTUP_HOME, CARGO_HOME, SSH agent variables, and the grant variable itself. Worker lifecycle commands receive only a small execution baseline, synthetic per-run HOME and CARGO_HOME directories, and operator-granted names; unrelated coordinator credentials are omitted. For SSH workers, granted values are made available to the SSH client and admitted into project commands only when the remote login environment supplies them, such as through deliberate OpenSSH SendEnv/AcceptEnv configuration. Values are never placed in the remote command line. SSH destinations are ASCII single aliases or user@host values without embedded options, ports, whitespace, or IPv6 syntax. Put ports, identity files, proxy jumps, host-key policy, credentials, and agent selection in OpenSSH configuration or an SSH agent. Temporary roots use an ASCII path whitelist and must be normalized, space-free, multi-component absolute paths whose physical resolution contains no symlink traversal. When present, smokeTestArgs must be a non-empty array of single-line, NUL-free strings and must not contain secrets.

Matrix builds capture the coordinator repository's effective minimumReleaseAge, minimumReleaseAgeStrict, and minimumReleaseAgeExclude values using individual pnpm config get <key> --json calls. These three nonsecret policy values travel to every local and SSH worker through tSRust-owned PNPM_CONFIG_MINIMUM_RELEASE_AGE, PNPM_CONFIG_MINIMUM_RELEASE_AGE_STRICT, and PNPM_CONFIG_MINIMUM_RELEASE_AGE_EXCLUDE environment variables. These names cannot be requested through forwardEnvironment. Global scope exclusions and repository overrides therefore survive the synthetic worker home. SSH transport shell-quotes the policy values; unlike granted credentials, these nonsecret values are included in the remote command. Registry and authentication configuration is never enumerated or copied, and the coordinator process environment remains unchanged. Values must be valid JSON with a nonnegative integer age, boolean strictness, and a string-array exclusion list; unset values remain unset. The policy is limited to 32 KiB, at most 512 exclusions, and 1,024 characters per exclusion. Each worker reads all three values back before installation and fails if they differ from the captured policy. There is no age-gate bypass or fallback policy.

matrix check validates the coordinator's package-age policy and verifies the exact project-local tsrust package version without executing its binary, the native linker, system Cargo plus rustup with an active default toolchain and readable target manifest or the complete securely resolved bundled pair with cargo, rustc, and target-manifest readiness bound to that worker's exact managed stable toolchain, worker identity, emulation or cross-execution, and remote-root ownership and permissions. It is a capability-only command: it does not require a clean worktree or compare the working configuration with the committed plan. If usable system Cargo is unavailable and the bundled executables are either absent or securely resolved but not ready, it verifies only that curl is available for tsrust bootstrap or clean reinstall; it does not prove network access, install targets, or compile the project. The check creates the dedicated remote root with restrictive permissions when it is absent. Capability and cleanup commands have a five-minute limit. Dependency installation, configured verification, compilation, per-binary smoke execution, bundle upload, and bounded artifact retrieval share each worker's one-hour build limit.

Before a configured verification command runs, the worker selects usable system Cargo or prepares the bundled toolchain through the exact installed tsrust package. Bundled verification receives its host-specific Rustup selection and executable path while retaining the worker's private HOME and CARGO_HOME. This supports direct cargo, rustc and rustup calls inside verification scripts. Preparation failure prevents verification and artifact assembly; bootstrap and verification remain within the same worker deadline and process cleanup boundary.

Run the capability-only check before release metadata is created:

tsrust matrix check

Build and atomically publish the complete matrix from a clean exact Git commit:

tsrust matrix build

Every worker receives the same exact commit through a streamed Git bundle, installs with pnpm install --frozen-lockfile, revalidates the installed tsrust package version, invokes the project-local tsrust with explicit targets, and optionally executes every binary with smokeTestArgs. Local and remote project commands run with the restricted worker environment. Local and remote workers build in isolated clones, so an incomplete matrix never replaces an existing dist_rust. SSH workers use /bin/bash on Linux or /bin/zsh on macOS in login mode for builds, normal OpenSSH host verification, architecture and random-owner-marker validation on every lifecycle and transfer connection, locally and remotely byte-bounded non-login SSH streams for artifact retrieval, a heartbeat-bound process-group watchdog, and a unique mode-0700 child below the configured root. Remote owner-validated cleanup is a pre-publication gate: failure preserves the prior dist_rust and reports retained diagnostics. After successful assembly, failure to remove local staging emits a warning but does not reverse the committed publication.

matrix build additionally requires the normalized resolved matrix policy to match committed .smartconfig.json at the captured commit, a clean Git worktree without skip-worktree or assume-unchanged flags, package name and version, a frozen pnpm lockfile, and at least one Cargo binary. Matrix transport rejects Git submodules, tracked symbolic links, checkout filters, and external-content pointer records because those inputs are not self-contained regular files in a plain exact-commit bundle. Source compatibility, index flags, and the clean Git snapshot are revalidated around bundle creation and after project-controlled build and smoke commands. Binaries are limited to 2 GiB each, provenance sidecars to 1 MiB each, and an assembly to 8 GiB total. Worker keys are expected host identities, not network addresses. Keep only the SSH destination and temporary root in the referenced variables; keys and credentials remain in OpenSSH configuration or an agent. Failed workspaces are intentionally retained and are not pruned automatically; each local and remote root admits at most three retained failed runs and then requires the operator to inspect and remove the exact reported paths before retrying.

Matrix workers are trusted execution principals, not sandboxes. A release therefore trusts the reviewed exact source commit, its lockfile-selected dependencies and lifecycle/build scripts, the selected local and SSH hosts, their toolchains and login configuration, and the registries they contact. Environment filtering, owner markers, source checks, bounded transfers, provenance digests, and transactional publication prevent accidental credential inheritance, stale or incomplete inputs, endpoint mix-ups, and partial publication; they do not contain deliberately malicious code already running as the same operating-system user. Use a separately isolated worker account or container when that trust assumption does not hold.

Static Linking

tsrust can produce fully statically linked Linux binaries (static-pie) that run on both glibc distros (Debian/Ubuntu) and musl distros (Alpine). Enable it via .smartconfig.json:

{
  "@git.zone/tsrust": {
    "targets": ["linux_amd64", "linux_arm64"],
    "static": true
  }
}

Or per invocation with the --static flag:

tsrust --static

Behavior per target:

  • *-linux-gnu: tsrust injects RUSTFLAGS="-C target-feature=+crt-static" into its cargo invocation.
  • *-linux-musl: already statically linked by default; no flags are injected.
  • *-apple-darwin: full static linking is not applicable on macOS; the target builds with default linkage.

After the build, tsrust verifies every Linux binary in dist_rust/ is actually statically linked (no PT_INTERP ELF program header — the check is architecture-independent, so cross-compiled binaries are verified too) and fails the build otherwise.

Why tsrust injects the flag instead of the project setting rustflags in rust/.cargo/config.toml:

  • tsrust always builds with an explicit --target, so the flag never applies to host artifacts. A repo-wide rustflags entry also applies to proc-macros and build scripts whenever cargo runs without --target (plain cargo test, cargo check, rust-analyzer) — and rustc cannot build proc-macros with +crt-static on linux-gnu, breaking those commands.
  • Keep rust/.cargo/config.toml free of rustflags when using static — the injected RUSTFLAGS environment variable replaces any config-file rustflags (cargo does not merge them). linker entries (e.g. for aarch64 cross-compilation) are unaffected and should stay.

Deterministic Path Remapping

Release binaries can embed absolute source paths in panic locations. Enable local path remapping to avoid publishing machine-specific paths:

{
  "@git.zone/tsrust": {
    "targets": ["linux_amd64", "linux_arm64"],
    "static": true,
    "remapLocalPaths": true
  }
}

remapLocalPaths adds Rust --remap-path-prefix flags for the project root, Rust source directory, Cargo home, and rustup home. Additional flags can be supplied explicitly through rustflags; these flags are combined with automatic flags such as -C target-feature=+crt-static for Linux GNU static builds:

{
  "@git.zone/tsrust": {
    "rustflags": ["--cfg=my_feature"]
  }
}

🗑️ Clean Only

Remove all build artifacts without rebuilding:

tsrust clean

This runs cargo clean in the Rust directory and deletes the dist_rust/ output directory.

🧹 Prune Rust Target Caches

Report Rust target caches without deleting anything:

tsrust prune

Apply cleanup to marked tsrust-managed target caches:

tsrust prune --apply --days 14 --max-size 5GiB
Option Description
--apply Remove marked managed target caches that match the filters
--days <n> Prune marked caches whose newest file is at least n days old; default 14
--max-size <size> Prune marked caches at or above a size such as 5GiB
--workspace <path> Inspect another workspace path

Conventional rust/target and ts_rust/target directories are report-only, even if they carry a marker. Only managed .nogit/tsrust* target directories are eligible for --apply; arbitrary app data is never marked or removed.

Project Structure

tsrust expects your project to follow this layout:

my-project/
├── rust/                   # 🦀 Your Rust source code
│   ├── Cargo.toml          #    Root manifest (workspace or single crate)
│   ├── src/
│   │   └── main.rs         #    (for single-crate projects)
│   └── crates/             #    (for workspace projects)
│       ├── my-binary/
│       │   ├── Cargo.toml  #    Contains [[bin]] targets
│       │   └── src/
│       └── my-lib/
│           ├── Cargo.toml
│           └── src/
├── dist_rust/              # 📦 Output: compiled binaries go here
│   ├── my-binary
│   └── my-binary.tsrust-build.json
├── .nogit/
│   └── tsrust-target/      # 🧹 Managed Cargo target cache
├── ts/                     #    (your TypeScript code, built by tsbuild)
├── dist_ts/                #    (TypeScript output)
└── package.json

Workspace Support

tsrust fully supports Cargo workspaces. It reads the [workspace] section from your root Cargo.toml, iterates through all members, and discovers binary targets from each member crate's Cargo.toml.

Binary target discovery follows Cargo's own rules:

  • Explicit [[bin]] entries → uses the name field from each entry
  • Implicit binary → if no [[bin]] is declared but src/main.rs exists, uses the [package] name
  • Library-only crates → skipped (no binary output expected)

Fallback Directory

If no rust/ directory is found, tsrust checks for ts_rust/ as a fallback. This supports projects that use the ts_ prefix convention for all source directories.

Programmatic API

tsrust exports its internals for use in other Node.js/TypeScript tools:

import {
  ArtifactAssembler,
  CargoConfig,
  CargoRunner,
  FsHelpers,
  ProvenanceStore,
  NativeMatrixBuilder,
  TsRustCli,
  configuredAssemblyTargets,
  normalizeTargets,
  resolveBuildTargets,
  resolveManagedTargetDir,
} from '@git.zone/tsrust';

// Parse a Cargo workspace
const config = new CargoConfig('/path/to/rust');
const info = await config.parse();
console.log(info.isWorkspace);   // true
console.log(info.binTargets);    // ['rustproxy']

// Run cargo build
const runner = new CargoRunner('/path/to/rust');
const targetDir = resolveManagedTargetDir('/path/to/project');
const result = await runner.build({ debug: false, clean: false, targetDir });
console.log(result.success);     // true
console.log(result.exitCode);    // 0

// File helpers
await FsHelpers.ensureEmptyDir('/path/to/dist_rust');
await FsHelpers.copyFile(src, dest);
await FsHelpers.makeExecutable(dest);
const size = await FsHelpers.getFileSize(dest);
console.log(FsHelpers.formatFileSize(size));  // "13.4 MB"

Important exported build and artifact APIs:

API Purpose
resolveBuildTargets() Apply CLI, exact-host, OS-family, legacy, and native target precedence.
configuredAssemblyTargets() Normalize and deduplicate the union required for multi-host assembly.
normalizeTargets() Resolve friendly aliases and reject invalid or colliding target names.
ProvenanceStore Write, hash-verify, and read byte-preserving provenance sidecars.
ArtifactAssembler Validate and transactionally publish a complete exact-commit artifact matrix to dist_rust/.
NativeMatrixBuilder Check and build an isolated local/SSH native matrix, then delegate publication to ArtifactAssembler.
resolveMatrixPlan() / matrixHostKeys Validate matrix configuration and inspect its complete disjoint worker schedule.
MatrixCommandRunner Execute bounded matrix subprocesses with process-group, signal, timeout, input, and heartbeat ownership.
Matrix configuration and result types Type NativeMatrixBuilder, worker transports, resolved plans, and check/build results.
captureGitSnapshot() / assertGitSnapshotUnchanged() Capture and compare Git commit and worktree state around a build.
ProvenanceStamper Read legacy tsrust 1.7/1.8 embedded trailers; new builds use ProvenanceStore.

This repository contains open-source code licensed under the MIT License. A copy of the license can be found in the license file.

Please note: The MIT License does not grant permission to use the trade names, trademarks, service marks, or product names of the project, except as required for reasonable and customary use in describing the origin of the work and reproducing the content of the NOTICE file.

Trademarks

This project is owned and maintained by Task Venture Capital GmbH. The names and logos associated with Task Venture Capital GmbH and any related products or services are trademarks of Task Venture Capital GmbH or third parties, and are not included within the scope of the MIT license granted herein.

Use of these trademarks must comply with Task Venture Capital GmbH's Trademark Guidelines or the guidelines of the respective third-party owners, and any usage must be approved in writing. Third-party trademarks used herein are the property of their respective owners and used only in a descriptive manner, e.g. for an implementation of an API or similar.

Company Information

Task Venture Capital GmbH Registered at District Court Bremen HRB 35230 HB, Germany

For any legal inquiries or further information, please contact us via email at hello@task.vc.

By using this repository, you acknowledge that you have read this section, agree to comply with its terms, and understand that the licensing of the code does not imply endorsement by Task Venture Capital GmbH of any derivative works.

S
Description
No description provided
Readme
1.2 MiB
Languages
TypeScript 99.9%
JavaScript 0.1%