You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: update README with v2 refs and HTTP lifecycle guidance
- Update all action refs from v1 to v2
- Clarify HTTP server lifecycle options:
- Per-configuration lifecycle (fresh server per config)
- Shared server across multiple configurations
- Pre-deployed servers
Test both stdio and HTTP transports in a single run using the `configurations` input:
138
138
139
139
```yaml
140
-
- uses: SamMorrowDrums/mcp-conformance-action@v1
140
+
- uses: SamMorrowDrums/mcp-conformance-action@v2
141
141
with:
142
142
setup_node: true
143
143
install_command: npm ci
@@ -258,10 +258,10 @@ Differences appear as unified diffs in the report. Common changes include:
258
258
259
259
### stdio Transport
260
260
261
-
The default transport communicates with your server via stdin/stdout using JSON-RPC:
261
+
The default transport communicates with your server via stdin/stdout using JSON-RPC. For stdio, each configuration spawns a fresh server process:
262
262
263
263
```yaml
264
-
- uses: SamMorrowDrums/mcp-conformance-action@v1
264
+
- uses: SamMorrowDrums/mcp-conformance-action@v2
265
265
with:
266
266
setup_node: true
267
267
install_command: npm ci
@@ -271,48 +271,51 @@ The default transport communicates with your server via stdin/stdout using JSON-
271
271
272
272
### Streamable HTTP Transport
273
273
274
-
For servers exposing an HTTP endpoint, the action can automatically manage the server lifecycle. Use `start_command` and the action will spawn your server, wait for it to start, probe it, then shut it down:
275
-
276
-
```yaml
277
-
- uses: SamMorrowDrums/mcp-conformance-action@v1
278
-
with:
279
-
setup_node: true
280
-
install_command: npm ci
281
-
build_command: npm run build
282
-
configurations: |
283
-
[{
284
-
"name": "http-server",
285
-
"transport": "streamable-http",
286
-
"start_command": "node dist/http.js",
287
-
"server_url": "http://localhost:3000/mcp",
288
-
"startup_wait_ms": 2000
289
-
}]
290
-
```
291
-
292
-
The action will:
293
-
1. Start the server using `start_command`
294
-
2. Wait `startup_wait_ms` (default: 2000ms) for the server to initialize
295
-
3. Send MCP requests via HTTP POST
296
-
4. Terminate the server after tests complete
297
-
298
-
For more control, you can use `pre_test_command` and `post_test_command` to manage server lifecycle yourself:
274
+
For HTTP servers, you typically want to **start the server once** and test multiple configurations against it. Use `start_command` at the configuration level—the action spawns the server, waits for startup, probes it, then terminates it after that configuration completes:
For pre-deployed servers, omit both `start_command` and `pre_test_command`:
287
+
**Per-configuration server lifecycle**: If your use case requires a fresh server instance per configuration (e.g., testing different flags or environment variables), include `start_command` in each configuration—each will get its own server process started and stopped.
288
+
289
+
**Shared server for multiple configurations**: If you want one HTTP server to handle multiple test configurations, use `pre_test_command`/`post_test_command` on the first/last configuration, or start the server in a prior workflow step:
0 commit comments