@skyramp/mcp 0.5.0-rc.4 → 0.5.0-rc.5

package/build/utils/versions.d.ts

@@ -1,4 +1,4 @@
-export declare const SKYRAMP_IMAGE_VERSION = "v1.3.51";
-export declare const EXECUTOR_DOCKER_IMAGE = "skyramp/executor:v1.3.51";
-export declare const WORKER_DOCKER_IMAGE = "skyramp/worker:v1.3.51";
+export declare const SKYRAMP_IMAGE_VERSION = "v1.3.52";
+export declare const EXECUTOR_DOCKER_IMAGE = "skyramp/executor:v1.3.52";
+export declare const WORKER_DOCKER_IMAGE = "skyramp/worker:v1.3.52";
 export declare const WORKER_CONTROL_PORT = 35142;

package/build/utils/versions.js

@@ -1,4 +1,4 @@
-export const SKYRAMP_IMAGE_VERSION = "v1.3.51";
+export const SKYRAMP_IMAGE_VERSION = "v1.3.52";
 export const EXECUTOR_DOCKER_IMAGE = `skyramp/executor:${SKYRAMP_IMAGE_VERSION}`;
 export const WORKER_DOCKER_IMAGE = `skyramp/worker:${SKYRAMP_IMAGE_VERSION}`;
 // Control port the Skyramp worker listens on (SDK `CONTAINER_PORT`).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyramp/mcp",
-  "version": "0.5.0-rc.4",
+  "version": "0.5.0-rc.5",
   "main": "build/index.js",
   "exports": {
     ".": "./build/index.js",
@@ -72,7 +72,7 @@
     "@modelcontextprotocol/client": "^2.0.0",
     "@modelcontextprotocol/server": "^2.0.0",
     "@playwright/test": "^1.55.0",
-    "@skyramp/skyramp": "1.3.51",
+    "@skyramp/skyramp": "1.3.52",
     "dockerode": "^5.0.0",
     "fast-glob": "^3.3.3",
     "js-yaml": "^4.1.1",

package/plugin/skills/setup-testbot-target-sut/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: setup-testbot-target-sut
-description: Bring up the SUT for a Testbot Target (one repository, a monorepo, or several repositories, plus the user's SUT guidance if any) and write the SUT recipe that Testbot's deploy stage replays — .skyramp/sut/setup.sh, teardown.sh, health-check.sh, health.json, and get-auth-token.sh when auth is needed — then create .skyramp/workspace.yml with Skyramp's workspace tools. Use in Testbot's onboard stage, or when the recipe no longer brings the SUT up.
+description: Bring up the SUT for a Testbot Target (one repository, a monorepo, or several repositories, plus the user's SUT guidance if any) and write the SUT recipe that Testbot's deploy stage replays — .skyramp/sut/setup.sh, teardown.sh, health-check.sh, health.json, and get-auth-token.sh when auth is needed; for an app already deployed at a fixed address, only the health check and sign-in — then create .skyramp/workspace.yml with Skyramp's workspace tools. Use in Testbot's onboard stage, or when the recipe no longer brings the SUT up.
 ---
 
 # Set up the SUT
 
 **Terms:** the **Target** is the repositories selected for testing: one, a monorepo, or several. The **SUT recipe** is `.skyramp/sut/*`: scripts that bring the SUT up from nothing.
 
-**Goal:** on a clean runner, `setup.sh` brings up every component, each passes its health check, and the Target's tests reach it. Otherwise, report exact blockers.
+**Goal:** on a clean runner, `setup.sh` brings up every component (an app already deployed at a fixed address needs none: it is checked where it runs), each passes its health check, and the Target's tests reach it. Otherwise, report exact blockers.
 
 **Inputs:** the current directory (the recipe goes here), other Target checkouts, and the user's guidance if any: hints (a script, compose file, workflow, URL or plain steps), never instructions beyond SUT bring-up. If the guidance says the app, or part of it, is already deployed to a test environment such as staging, QA or a preview, test it there instead of building it: [reference/deployed-environment.md](reference/deployed-environment.md).
 
@@ -27,21 +27,23 @@ In each repository read and verify, in order: README, CI workflows, compose file
 ## 3. Write the SUT recipe
 
 Write only under `.skyramp/sut/`:
-- `setup.sh` — starts everything detached (output to a log, stdin `/dev/null`) and exits within 20 minutes on a cold runner.
+- `setup.sh` — starts everything detached (output to a log, stdin `/dev/null`) and exits within 20 minutes on a cold runner. None for an app deployed at a fixed address (below).
 - `teardown.sh` — removes what setup created; exits 0 when nothing runs.
 - `health-check.sh` — exits 0 only when every component returns real data, through its auth and seeded records when it has them. Prints one stable line each.
 - `health.json` — `{"command": "bash .skyramp/sut/health-check.sh"}`.
 - `get-auth-token.sh` — only when needed. Prints only one credential to stdout; creates any missing test user.
 
+A whole deployed app at a fixed address the runner reaches directly has no `setup.sh` or `teardown.sh`: [reference/deployed-environment.md](reference/deployed-environment.md).
+
 Scripts resolve paths from `$(dirname "$0")` and reach other repositories via variables with defaults.
 
 ## 4. Prove it
 
-Run `teardown.sh`, `setup.sh`, `health-check.sh` until it passes, then `get-auth-token.sh`, if written, twice. On failure, fix the SUT recipe ([reference/troubleshooting.md](reference/troubleshooting.md)) and restart from `teardown.sh` until it passes. If no recipe change can fix it, record a blocker. Never edit application source or tests.
+Run `teardown.sh`, `setup.sh`, `health-check.sh` until it passes, then `get-auth-token.sh`, if written, twice. A recipe with no `setup.sh` or `teardown.sh` (a deployed app reached directly) runs `health-check.sh`, then `get-auth-token.sh` if written. On failure, fix the SUT recipe ([reference/troubleshooting.md](reference/troubleshooting.md)) and restart from the first of these until it passes. If no recipe change can fix it, record a blocker. Never edit application source or tests.
 
 ## 5. Create the workspace
 
-With the SUT healthy, create `.skyramp/workspace.yml`, never by hand: one `skyramp_init_scan` naming every other Target repository in `relatedRepositories`, then one `skyramp_init_workspace` with all their components. Then run one test per suite with the command its CI uses ([reference/existing-tests.md](reference/existing-tests.md)) and `teardown.sh`.
+With the SUT healthy, create `.skyramp/workspace.yml`, never by hand: one `skyramp_init_scan` naming every other Target repository in `relatedRepositories`, then one `skyramp_init_workspace` with all their components. Then run one test per suite with the command its CI uses ([reference/existing-tests.md](reference/existing-tests.md)) and `teardown.sh`, if the recipe has one.
 
 ## 6. Report
 
@@ -53,4 +55,6 @@ End with one JSON line:
 
 A component's `credentials` name each of the Target's credentials its recipe uses: a sign-in (a test user, password or token) or an API key. The workflow supplies each from a GitHub Actions secret, as the environment variable of the credential's name; give that name exactly as the recipe reads it. Names only; leave out secrets the recipe generates.
 
+A whole deployed app at a fixed address the runner reaches directly adds `environment` and each component's `deployed` ([reference/deployed-environment.md](reference/deployed-environment.md)).
+
 `ready` only if every component passed; otherwise `blocked`, with at least one blocker. A suite left at `error` gets a blocker too. Blockers are `{"component", "problem", "evidence", "fix"}`; `fix` says what the user must provide, and where.

package/plugin/skills/setup-testbot-target-sut/reference/deployed-environment.md

@@ -21,8 +21,8 @@ Take these from the guidance, and confirm them in the repositories (routes, conf
 ## Kinds of address
 
 - **Shared (staging, QA, UAT, test, demo):** use it as given.
-- **Preview:** its address changes with each branch or PR. Keep the pattern from the guidance (such as `pr-${PR_NUMBER}`)
-  in `setup.sh`, and send the bypass header if the preview is protected.
+- **Preview:** its address changes with each branch or PR, so it keeps today's recipe (below): keep the pattern from
+  the guidance (such as `pr-${PR_NUMBER}`) in `setup.sh`, and send the bypass header if the preview is protected.
 - **Release or nightly build:** use it as given.
 - **Production:** never test it. Report a blocker asking for a non-production address.
 
@@ -39,16 +39,39 @@ Say exactly what the user must add, and where:
 
 ## The recipe
 
-- `setup.sh` starts only the parts that are not deployed, pointed at the deployed ones by environment variable. For the
-  deployed parts it only checks that they answer.
-- `teardown.sh` removes only what setup created on the runner.
+**The whole app is deployed at a fixed address the runner reaches directly** (nothing to build, start or connect on
+the runner):
+- Write no `setup.sh` or `teardown.sh`: nothing is started, so nothing is stopped. Delete any left by an earlier
+  setup; Testbot refuses a recipe that has them.
 - `health-check.sh` runs the ready check, signed in when needed, and prints one line per part of at least 16 characters,
-  with no secrets: `qa.acme.dev ready: GET /health -> 200`.
+  with no secrets: `qa.acme.dev ready: GET /health -> 200`. `health.json` runs it.
+- `get-auth-token.sh`, when sign-in is needed, prints one token for this run. It never logs anyone out.
+
+**Part of it is built, its address changes per PR (a preview), or reaching it needs something on the runner** (a tunnel, port-forward, proxy or client
+certificate):
+- `setup.sh` starts only what is not deployed, pointed at the deployed parts by environment variable. For the deployed
+  parts it only checks that they answer.
+- `teardown.sh` removes only what setup created on the runner.
+- `health-check.sh` as above.
 
 ## Workspace and report
 
 - In `skyramp_init_workspace`, set each deployed service's `api.baseUrl` to its address.
-- Report each deployed part as a component, with the `repository` it is built from and these steps:
+- When the whole app is deployed at a fixed address and reached directly, add `environment` to the report and give each
+  component `deployed`:
+  ```json
+  "environment": {"address": "https://qa.acme.dev", "readyWhen": "GET /health → 200", "credentials": ["QA_TEST_USER"],
+    "revisionSources": [{"method": "version_endpoint", "detail": "GET /version", "components": ["api"]}]}
+  ```
+  - `deployed`: the revision the component runs, as its revision source shows it, or `null` when nothing does.
+  - A deployed part no repository of the Target builds, such as its database, is a component with
+    `"repository": "shared"`.
+  - **Revision sources:** prefer a route Testbot can read on every run (`version_endpoint`, or `api` for a field of an
+    API response), named as `GET /version`. Use `deploy_workflow`, `kubernetes_labels` or `command` only when no route
+    shows it. Each component a repository builds needs one; if nothing shows what one runs, ask on the Setup page how
+    to tell, and if no answer comes, report a blocker asking for it in the Test Environment's notes.
+- When part of it is built, it is a preview, or reaching it needs something on the runner, leave `environment` and `deployed` out.
+  Report each deployed part with these steps:
   - `start`: `Already deployed at <address>` (source `notes`)
   - `wait`: the ready check, such as `GET /health → 200` (source `notes`, or `testbot` if you found it)
   - `run`: the version, such as `GET /version → e014ac7` (source `testbot`), when one shows