golem-integration-test-setup

Configure an isolated Golem test environment and deploy via discovered ports.

Updated May 17, 2026
One-click install
npx skills add https://github.com/Rust-soham/golem-claw --skill golem-integration-test-setup
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: golem-integration-test-setup
Source: https://github.com/Rust-soham/golem-claw/tree/main/packages/golem/.agents/skills/golem-integration-test-setup
Command: npx skills add https://github.com/Rust-soham/golem-claw --skill golem-integration-test-setup

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Integration tests for Golem apps often interfere with local development state or collide across CI runs, and they can fail due to race conditions from starting requests before the server is ready.

Core Features & Use Cases

  • Isolated test environment configuration: Adds a dedicated test (or integration) environment in golem.yaml so tests deploy and target their own setup.
  • Deterministic, non-interactive deploys: Enables cli.autoConfirm and cli.reset so golem -E test deploy runs without prompts and starts from a clean deployment each time.
  • Reliable port discovery for test harnesses: Starts an isolated golem server run using --data-dir plus random available ports (--*-port 0) and reads the actual bound ports from --ports-file for HTTP/MCP routing.

Quick Start

Configure a test environment in your golem.yaml, then run an isolated golem server run with --data-dir and --ports-file for readiness, and finally deploy with golem -E test deploy.

Frequently Asked Questions about golem-integration-test-setup

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run isolated integration tests for Golem apps without colliding with local state?

Isolated integration tests require a dedicated `test` environment in `golem.yaml` and an isolated `golem server run` with `--data-dir` to prevent state collisions. This setup ensures CI and local harnesses deploy to their own clean instances.

How do I prevent race conditions when starting Golem server requests before it is ready?

Prevent race conditions by starting `golem server run` with `--ports-file` and waiting for server readiness by reading the discovered port values. This ensures HTTP/MCP request routing only begins after the server is fully bound.

How do I set up deterministic, non-interactive Golem deployments for CI?

Deterministic deployments use `cli.autoConfirm` and `cli.reset` in your `golem.yaml` configuration so `golem -E test deploy` runs without prompts. This ensures CI pipelines execute non-interactive deploys from a clean state each time.

How does dynamic port binding work for isolated Golem server test instances?

Dynamic port binding uses `--*-port 0` to assign random available ports, writing the actual bound values to a file via `--ports-file`. Test harnesses read this file to route HTTP/MCP requests to the correct dynamic ports.

Can I run multiple Golem server instances simultaneously for parallel end-to-end testing?

Yes, parallel end-to-end testing is possible by starting isolated `golem server run` instances with unique `--data-dir` and random `--*-port 0` configurations. Each instance discovers its own ports, preventing cross-instance collisions.

Why do my integration tests fail due to port conflicts when starting Golem servers?

Port conflicts occur without dynamic binding. Starting `golem server run` with `--*-port 0` binds random available ports, and `--ports-file` records the actual values for reliable HTTP/MCP request routing, eliminating conflicts.