@colony2/pulse

中文文档
0.0.24发布于 2026/11/09Apache-2.0零依赖构建来源已验证近 30 天下载 2707

Container compute orchestration for c2j jobs

原始使用文档
文档目录11 节
  1. Install
  2. npm
  3. Native executable
  4. Quick start
  5. Run in a container
  6. Configuration
  7. Providers
  8. HTTP API
  9. More documentation
  10. License
  11. Local provider plugins

Pulse

Run c2j jobs on cloud compute or your own runners.

Pulse watches all repositories in a JobDB tenant, finds jobs that need an executor, acquires a JobDB lease for each selected job, and passes it to the container. It uses c2j's public Go library for discovery and tags each launch with its JobDB identity. The controller needs no separate c2j executable; executor images must contain c2j and the tools their recipes need.

Install · Quick start · Run in a container · Configuration · Providers · HTTP API

Install

npm

npm install --global @colony2/pulse
pulse version

Requires Node.js 22+, tar, enabled install scripts, and HTTPS access to GitHub Releases. The installer downloads the matching native executable and verifies the archive SHA-256 checksum.

Native executable

Download your platform's archive from GitHub Releases, verify it against checksums.txt, and put pulse on your PATH. Native executables need no Node.js. Archives also contain the optional Linux pulse-exec bridge for cloud providers. Docker needs only the Pulse executable.

Linux and macOS are supported on AMD64 and ARM64. Container images support Linux AMD64 and ARM64. The local Docker provider supports Linux servers and Docker Desktop on macOS, using Pulse's automatic Docker socket/context discovery.

Quick start

Start Docker Engine on Linux or Docker Desktop on macOS, then run:

pulse

No Pulse configuration file is required. Pulse uses the same tenant settings as c2j: C2J_JOBDB, then jobdb in the nearest .c2/config.yaml. You can also select a tenant explicitly:

pulse run --jobdb https://jobdb.example.com/acme
pulse check
pulse run --once
pulse version

Pulse discovers eligible c2j jobs across every repository in the tenant. Docker is the default provider, and jobs without an image/base request use the selector ubuntu-26*, resolving to a supported Ubuntu 26.04 base backed by ghcr.io/colony-2/base2:latest. Jobs without resource requirements have no CPU, memory, or scratch allocation, and Docker has no default container-count cap. Docker detects native and emulated execution support and prefers its daemon's native architecture on macOS and Linux. Explicit base selectors still constrain the architecture.

For Colony base images, Docker automatically retains uv, pnpm, and Nix dependencies in tenant-scoped volumes across jobs and restarts. No Nix daemon or manual cache setup is needed. See cache settings and image prerequisites.

check validates settings and initializes providers; it does not verify remote connectivity or launch permissions. run --once performs one discovery/submission pass. Both pulse and pulse run keep polling until SIGINT or SIGTERM and write JSON logs to stderr. Launched containers continue under their own lifetime controls.

For independently implemented Go providers, see the Go provider guide. Pulse uses the zero-dependency provider API; custom binaries can register implementations without plugins.

For custom providers or multiple tenants, use an optional configuration: remote runners, local Docker overrides, or cloud providers. Executor images must include c2j with run with-lease support; cloud images also need pulse-exec. Use a JobDB server containing commit 39ae1b444460 or later with available-route discovery and supplied-lease renewal support; upgrade the server alongside Pulse.

Run in a container

Use ghcr.io/colony-2/pulse. For simple deployments, pass the complete YAML in PULSE_CONFIG. Start with examples/container.yaml, fill in the settings, then run:

export PULSE_CONFIG="$(cat pulse.yaml)"
docker run --rm --init \
  --read-only --tmpfs /tmp -p 8080:8080 \
  -e PULSE_CONFIG -e PULSE_PROVIDER_TOKEN \
  ghcr.io/colony-2/pulse:latest

The file is read on the host. In a deployment console, set PULSE_CONFIG directly to the YAML contents. Keep credentials in separate secret/environment settings or use the hosting platform's identity. For repeatable deployments, select a release tag such as :vX.Y.Z or an image digest.

The image is distroless, runs as UID/GID 65532:65532, and contains Pulse, its execution supervisor, and CA certificates. It includes native cloud authentication and needs no shell, Node.js, Git, cloud CLI, or separate c2j executable. Configure defaults.base with an environment selector. Legacy defaults.image plus defaults.platform remain supported for explicit OCI images.

For mounted YAML, pass the file path explicitly:

docker run --rm --init --read-only --tmpfs /tmp -p 8080:8080 \
  --mount "type=bind,source=$PWD/pulse.yaml,target=/etc/pulse/pulse.yaml,readonly" \
  -e PULSE_PROVIDER_TOKEN \
  ghcr.io/colony-2/pulse:latest --config /etc/pulse/pulse.yaml

The mounted file must be readable by UID 65532. See configuration and Cloud Run deployment, cloud authentication, and Docker socket setup.

Configuration

Pulse optionally loads one YAML document, in order:

  1. Explicit --config PATH.
  2. PULSE_CONFIG containing the YAML itself.
  3. ./pulse.yaml, if present.
  4. Built-in defaults.

Sources are not merged. Empty or invalid inline configuration fails startup unless an explicit file was selected. Values are literal, without environment-placeholder expansion. Restart or redeploy to apply changes.

Tenant selection uses --jobdb, an explicit Pulse target's jobdb, C2J_JOBDB, then c2j project settings. Each target covers the whole tenant. Missing instance_id values are derived from the JobDB deployment URL. Remove obsolete cells settings when upgrading. Pulse requires an HTTP(S) JobDB tenant; c2j's embedded database cannot serve container workers.

Launch services have positive numeric priorities: 1 is preferred over 2. Equal-priority services rotate first choice for each batch. A provider can accept part of a batch and decline the rest for fallback.

targets:
  - instance_id: production
    jobdb: https://jobdb.example.com/acme
    jobdb_token_env: JOBDB_TOKEN
    launch_services:
      - {name: runner_pool_a, priority: 1}
      - {name: runner_pool_b, priority: 1}
      - {name: cloud_overflow, priority: 2}

Define these service names under providers and supply JOBDB_TOKEN for authenticated JobDB discovery and lease acquisition. Pulse never passes this broad credential to the executor. Omit jobdb_token_env for an unauthenticated deployment. Provider authentication is configured separately.

When providers is omitted or empty, Pulse enables a local provider named docker. On Apple Silicon macOS with tart on PATH, it also enables tart using pulse-tart’s default two macOS and four Linux job VMs (4 vCPU / 8 GiB each; Linux includes Docker). Targets without launch_services prefer Docker at priority 1, then Tart at priority 2. Explicit provider maps remain authoritative. The default base is ubuntu-26*; select defaults.base: 'macos*' for macOS work. See Tart and Orchard configuration.

The default Docker pool uses the daemon’s CPU and memory capacity, with no container-count cap and 256 MiB accounting overhead per container. Start Docker Engine or Docker Desktop. Docker launches c2j directly and supplies its lease over native stdin, with no host mounts or helper installation. See Docker defaults and overrides.

c2j owns recipe and operation timeouts; Pulse imposes no execution timeout by default. Optional infrastructure caps must be configured explicitly and supported by the selected provider. Defaults are a 5-second poll interval, a 5-minute lease duration, 60-second provisioning-failure backoff, and batches of at most 100 jobs. Claims run with up to 8 concurrent calls and a 5-second claim window; configure these with claim_concurrency, claim_timeout, and batch_size. Pulse acquires the lease before submission and does not renew it; c2j renews the supplied lease on startup. Accepted or uncertain starts rely on lease expiry for recovery. Definite non-starts release the lease with backoff. In-memory cooldowns suppress failures only; JobDB ownership survives controller restarts. See configuration details and the complete examples.

Providers

ProviderTypeNotes
Local DockerdockerCPU, memory, and container-count budgets; no disk quotas.
Local TarttartmacOS and Linux ARM64 VMs, with Docker included on Linux guests and opt-in Docker on macOS; automatically enabled on Apple Silicon Macs with Tart installed.
OrchardorchardmacOS and Linux ARM64 VMs; Linux includes Docker, macOS Docker is opt-in on a configured Orchard worker.
Remote runner serviceremoteBatch submission with partial acceptance and capacity fallback.
Google Cloud Run JobscloudrunNative job execution and supported resource sizes.
AWS ECS FargateecsStandalone tasks with the execution supervisor.
Azure Container Apps JobsazurejobsManual jobs with native execution timeouts.

In cloud environments, attach a service account, task/instance role, or managed/workload identity to the controller. Elsewhere, supply supported environment credentials or mounted credential files. See cloud authentication and provider operations for permissions, image requirements, capacity, and resource cleanup.

HTTP API

Continuous mode serves a public, unauthenticated, read-only API on :8080. PORT changes the default port; http.listen can override the address.

GET endpointReturns
/statusVersion, uptime, and polling status.
/configConfiguration with environment values and URL credentials redacted.
/instancesActive instances across all configured providers.
/providers/{provider}/instancesOne page from a configured provider.
/scheduler/cooldownsCurrent cooldowns and in-flight attempts.
/scheduler/round-robinPriority tiers and next starting services.
curl http://localhost:8080/status
curl 'http://localhost:8080/providers/runners/instances?page_size=100'

Lists include queued, starting, and running instances and exclude terminal instances; paused/stopping compute is included where supported. run --once, check, and version do not start the server. See HTTP API documentation for pagination and partial failures.

More documentation

License

Apache-2.0.

Local provider plugins

Use type: plugin to run a trusted, independently installed compute provider. Pulse starts and supervises the executable, delivers only its configuration, and preserves uncertain submission outcomes without replay. See installation and the public SDK and the separate-module reference provider.

版本与发布记录

@colony2/pulse 共发布 20 个版本,首次发布于 2026/09/24;过去 12 个月发布了 20 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
0.0.24latest2026/11/091 天前
0.0.232026/11/091 天前
0.0.222026/11/055 天前
0.0.212026/11/046 天前
0.0.202026/11/028 天前
0.0.192026/11/028 天前

关于 @colony2/pulse 的常见问题

@colony2/pulse 是什么?

Container compute orchestration for c2j jobs

如何安装 @colony2/pulse?

在项目目录运行 npm install @colony2/pulse,或使用 pnpm add / yarn add / bun add。它还提供命令行工具 pulse,可以用 npx pulse 直接运行。

@colony2/pulse 支持 TypeScript 吗?

该包的 package.json 没有声明类型入口。需要类型提示时,可以在 npm 上查找社区维护的 @types/colony2__pulse 是否存在。

@colony2/pulse 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=22.0.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@colony2/pulse 可以商用吗?

@colony2/pulse 使用 Apache-2.0 许可。宽松许可:允许商业使用、修改和再分发,并附带明确的专利授权;分发时需保留许可与 NOTICE 文件,修改过的文件要注明改动。以上为概括,不构成法律意见,请以许可原文为准。

@colony2/pulse 的下载量有多少?

根据 npm 官方下载统计,@colony2/pulse 在 2026/10/11 – 2026/11/09 这 30 天内被下载 2,707 次,日均约 90 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@colony2/pulse 还在维护吗?

最新版本 0.0.24 发布于 2026/11/09(1 天前);至今共发布 20 个版本,其中过去 12 个月发布了 20 个;首次发布于 2026/09/24。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。