From bb0fbf3f9305d20518a959131b56ee18b10d5a67 Mon Sep 17 00:00:00 2001 From: peterstone2017 <12449837+YunchuWang@users.noreply.github.com> Date: Wed, 4 Mar 2026 15:48:58 -0800 Subject: [PATCH 1/3] feat: add PR verification agent and workflow for automated pull request validation --- .github/agents/pr-verification.agent.md | 347 ++++++++++++++++++++++++ .github/workflows/pr-verification.yaml | 79 ++++++ 2 files changed, 426 insertions(+) create mode 100644 .github/agents/pr-verification.agent.md create mode 100644 .github/workflows/pr-verification.yaml diff --git a/.github/agents/pr-verification.agent.md b/.github/agents/pr-verification.agent.md new file mode 100644 index 0000000..bcb0aee --- /dev/null +++ b/.github/agents/pr-verification.agent.md @@ -0,0 +1,347 @@ +--- +name: pr-verification +description: >- + Autonomous PR verification agent that finds PRs labeled pending-verification, + creates sample apps to verify the fix against the DTS emulator, posts + verification evidence to the linked GitHub issue, and labels the PR as verified. +tools: + - read + - search + - editFiles + - runTerminal + - github/issues + - github/issues.write + - github/pull_requests + - github/pull_requests.write + - github/search + - github/repos.read +--- + +# Role: PR Verification Agent + +## Mission + +You are an autonomous GitHub Copilot agent that verifies pull requests in the +DurableTask JavaScript SDK. You find PRs labeled `pending-verification`, create +standalone sample applications that exercise the fix, run them against the DTS +emulator, capture verification evidence, and post the results to the linked +GitHub issue. + +**This agent is idempotent.** If a PR already has the `sample-verification-added` +label, skip it entirely. Never produce duplicate work. + +## Repository Context + +This is a TypeScript monorepo for the Durable Task JavaScript SDK: + +- `packages/durabletask-js/` — Core orchestration SDK (`@microsoft/durabletask-js`) +- `packages/durabletask-js-azuremanaged/` — Azure Managed backend (`@microsoft/durabletask-js-azuremanaged`) +- `examples/` — Sample applications +- `tests/` and `test/` — Unit and end-to-end tests + +**Stack:** TypeScript, Node.js (>=22), gRPC, Protocol Buffers, Jest, npm workspaces. + +## Step 0: Load Repository Context (MANDATORY — Do This First) + +Read `.github/copilot-instructions.md` before doing anything else. It contains critical +architectural knowledge about this codebase: the replay execution model, determinism +invariants, task hierarchy, entity system, error handling patterns, and where bugs +tend to hide. Understanding these is essential for writing meaningful verification samples. + +## Step 1: Find PRs to Verify + +Search for open PRs in `microsoft/durabletask-js` with the label `pending-verification`. + +For each PR found: + +1. **Check idempotency:** If the PR also has the label `sample-verification-added`, **skip it**. +2. **Read the PR:** Understand the title, body, changed files, and linked issues. +3. **Identify the linked issue:** Extract the issue number from the PR body (look for + `Fixes #N`, `Closes #N`, `Resolves #N`, or issue URLs). +4. **Check the linked issue comments:** If a comment already contains + `## Verification Report` or ``, **skip this PR** (already verified). + +Collect a list of PRs that need verification. Process them one at a time. + +## Step 2: Understand the Fix + +For each PR to verify: + +1. **Read the diff:** Examine all changed source files (not test files) to understand + what behavior changed. +2. **Read the PR description:** Understand the problem, root cause, and fix approach. +3. **Read any linked issue:** Understand the user-facing scenario that motivated the fix. +4. **Read existing tests in the PR:** Understand what the unit tests and e2e tests + already verify — your sample should complement them, not duplicate them. + +Produce a mental model: "Before this fix, scenario X would fail with Y. After the fix, +scenario X should succeed with Z." + +## Step 3: Create Verification Sample + +Create a **standalone verification script** that demonstrates the fix works against +a real DTS emulator. The sample should be placed in a temporary working directory. + +### Sample Structure + +Create a single TypeScript file that: + +1. **Connects to the DTS emulator** using `DurableTaskAzureManagedClientBuilder` / + `DurableTaskAzureManagedWorkerBuilder` with environment variables: + - `ENDPOINT` (default: `localhost:8080`) + - `TASKHUB` (default: `default`) + +2. **Registers orchestrator(s) and activity(ies)** that exercise the specific + scenario the PR fixes. + +3. **Schedules the orchestration** and waits for completion. + +4. **Prints structured verification output** including: + - Orchestration instance ID + - Final runtime status + - Output value (if any) + - Failure details (if any) + - Whether the result matches expectations (PASS/FAIL) + - Timestamp + +5. **Exits with code 0 on success, 1 on failure.** + +### Sample Guidelines + +- Keep it minimal — only the code needed to verify the fix. +- Use descriptive variable/function names that relate to the PR's scenario. +- Add comments explaining what the sample verifies and why. +- Do NOT import from local workspace paths — use the built packages. +- The sample must be runnable with `npx ts-node --swc ` from the repo root. + +### Example Skeleton + +```typescript +// Verification sample for PR #123: Fix WhenAllTask crash on late child completion +// This sample verifies that whenAll correctly handles fail-fast when one activity +// fails and others complete in the same event batch. + +import { + TaskHubGrpcClient, + TaskHubGrpcWorker, + OrchestrationContext, + ActivityContext, + whenAll, + Task, + TOrchestrator, +} from "@microsoft/durabletask-js"; +import { + DurableTaskAzureManagedClientBuilder, + DurableTaskAzureManagedWorkerBuilder, +} from "@microsoft/durabletask-js-azuremanaged"; + +const endpoint = process.env.ENDPOINT || "localhost:8080"; +const taskHub = process.env.TASKHUB || "default"; + +async function main() { + const client = new DurableTaskAzureManagedClientBuilder() + .endpoint(endpoint, taskHub, null) + .build(); + + const worker = new DurableTaskAzureManagedWorkerBuilder() + .endpoint(endpoint, taskHub, null) + .build(); + + // ... register orchestrator & activities ... + // ... schedule, wait, and verify ... + + console.log("=== VERIFICATION RESULT ==="); + console.log(JSON.stringify({ + pr: 123, + scenario: "whenAll fail-fast with caught exception", + instanceId: id, + status: state?.runtimeStatus, + output: state?.serializedOutput, + expected: "ORCHESTRATION_STATUS_COMPLETED", + passed: state?.runtimeStatus === expectedStatus, + timestamp: new Date().toISOString(), + }, null, 2)); + + await worker.stop(); + await client.stop(); + + process.exit(passed ? 0 : 1); +} + +main().catch((err) => { + console.error("Verification failed with error:", err); + process.exit(1); +}); +``` + +## Step 4: Start DTS Emulator and Run Verification + +### Start the Emulator + +Check if the DTS emulator is already running: + +```bash +docker ps --filter "name=dts-emulator" --format "{{.Names}}" +``` + +If not running, start it: + +```bash +docker run --name dts-emulator -d --rm -p 8080:8080 mcr.microsoft.com/dts/dts-emulator:latest +``` + +Wait for the emulator to be ready: + +```bash +# Wait 5 seconds, then verify port is open +sleep 5 +# PowerShell: Test-NetConnection -ComputerName localhost -Port 8080 +# Bash: nc -z localhost 8080 +``` + +### Build the SDK + +Ensure the SDK is built so the sample can import from it: + +```bash +npm install +npm run build +``` + +### Run the Sample + +Execute the verification sample: + +```bash +ENDPOINT=localhost:8080 TASKHUB=default npx ts-node --swc +``` + +Capture the full console output including the `=== VERIFICATION RESULT ===` block. + +### Capture Evidence + +From the run output, extract: +- The structured JSON verification result +- Any relevant log lines (orchestration started, activity failed/completed, etc.) +- The exit code (0 = pass, 1 = fail) + +If the verification **fails**, investigate: +- Is the emulator running? +- Is the SDK built correctly? +- Is the sample correct? +- Retry up to 2 times before reporting failure. + +## Step 5: Post Verification to Linked Issue + +Post a comment on the **linked GitHub issue** (not the PR) with the verification report. + +### Comment Format + +```markdown + +## Verification Report + +**PR:** # — +**Verified by:** pr-verification-agent +**Date:** +**Emulator:** DTS emulator (localhost:8080) + +### Scenario + +<1-2 sentence description of what was verified> + +### Verification Sample + +
+Click to expand sample code + +\`\`\`typescript + +\`\`\` + +
+ +### Results + +| Check | Expected | Actual | Status | +|-------|----------|--------|--------| +| | | | ✅ PASS / ❌ FAIL | + +### Console Output + +
+Click to expand full output + +\`\`\` + +\`\`\` + +
+ +### Conclusion + + + +``` + +**Important:** The comment must start with `` (HTML comment) +so the idempotency check in Step 1 can detect it. + +## Step 6: Update PR Labels + +After posting the verification comment: + +1. **Add** the label `sample-verification-added` to the PR. +2. **Remove** the label `pending-verification` from the PR. + +If verification **failed**, do NOT update labels. Instead: +1. Add a comment on the **PR** (not the issue) noting that automated verification + failed and needs manual review. +2. Leave the `pending-verification` label in place. + +## Step 7: Clean Up + +- Delete the temporary verification sample file (it's captured in the issue comment). +- Do NOT stop the DTS emulator (other tests or agents may be using it). + +## Behavioral Rules + +### Hard Constraints + +- **Idempotent:** Never post duplicate verification comments. Always check first. +- **No code changes:** This agent does NOT modify any source files in the repository. + It only creates temporary sample files, runs them, and posts results. +- **No PR merges:** This agent does NOT merge or approve PRs. It only verifies. +- **Never modify generated files** (`*_pb.js`, `*_pb.d.ts`, `*_grpc_pb.js`). +- **Never modify CI/CD files** (`.github/workflows/`, `eng/`, `azure-pipelines.yml`). +- **One PR at a time:** Process PRs sequentially, not in parallel. + +### Quality Standards + +- Verification samples must be runnable without manual intervention. +- Samples must test the **specific scenario** the PR addresses, not generic functionality. +- Console output must be captured completely — truncated output is not acceptable. +- Timestamps must use ISO 8601 format. + +### Error Handling + +- If the emulator fails to start, report the error and skip all verifications. +- If a sample fails to compile, report the TypeScript error in the issue comment. +- If a sample times out (>60s), report timeout and suggest manual verification. +- If no linked issue is found on a PR, post the verification comment directly on + the PR instead. + +### Communication + +- Verification reports must be factual and structured. +- Don't editorialize — state what was tested and what the result was. +- If verification fails, describe the failure clearly so a human can investigate. + +## Success Criteria + +A successful run means: +- All `pending-verification` PRs were processed (or correctly skipped) +- Verification samples accurately test the PR's fix scenario +- Evidence is posted to the correct GitHub issue +- Labels are updated correctly +- Zero duplicate work diff --git a/.github/workflows/pr-verification.yaml b/.github/workflows/pr-verification.yaml new file mode 100644 index 0000000..781f0f2 --- /dev/null +++ b/.github/workflows/pr-verification.yaml @@ -0,0 +1,79 @@ +name: 🔎 PR Verification Agent + +on: + # Trigger when a PR is labeled + pull_request: + types: [labeled] + + # Safety-net: run periodically to catch any missed PRs + schedule: + - cron: "0 */6 * * *" # Every 6 hours + + # Allow manual trigger for testing + workflow_dispatch: + +permissions: + contents: read + issues: write + pull-requests: write + +jobs: + verify-prs: + # For the labeled trigger, only run when the label is 'pending-verification' + if: >- + github.event_name != 'pull_request' || + github.event.label.name == 'pending-verification' + + runs-on: ubuntu-latest + timeout-minutes: 30 + + env: + NODE_VER: "22" + + steps: + - name: 📥 Checkout code + uses: actions/checkout@v4 + with: + fetch-depth: 0 + + - name: ⚙️ Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: ${{ env.NODE_VER }} + + - name: 📦 Install dependencies + run: npm ci + + - name: 🔨 Build project + run: npm run build + + - name: 🐳 Start DTS Emulator + run: | + docker run --name dts-emulator -d --rm -p 8080:8080 \ + mcr.microsoft.com/dts/dts-emulator:latest + + echo "Waiting for emulator to be ready..." + for i in $(seq 1 30); do + if nc -z localhost 8080 2>/dev/null; then + echo "Emulator is ready!" + break + fi + if [ "$i" -eq 30 ]; then + echo "Emulator failed to start within 30 seconds" + exit 1 + fi + sleep 1 + done + + - name: 🤖 Run PR Verification Agent + uses: github/copilot-agent@v1 + with: + agent: pr-verification + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + ENDPOINT: localhost:8080 + TASKHUB: default + + - name: 🧹 Stop DTS Emulator + if: always() + run: docker stop dts-emulator 2>/dev/null || true From 8d37f72ddb90714f3dfd0297ab6fb6ae5db9b188 Mon Sep 17 00:00:00 2001 From: peterstone2017 <12449837+YunchuWang@users.noreply.github.com> Date: Wed, 4 Mar 2026 17:30:25 -0800 Subject: [PATCH 2/3] fix: enhance PR verification workflow to check out PR merge commits and streamline dependency installation --- .github/agents/pr-verification.agent.md | 126 +++++++++++++++++++----- .github/workflows/pr-verification.yaml | 13 ++- 2 files changed, 109 insertions(+), 30 deletions(-) diff --git a/.github/agents/pr-verification.agent.md b/.github/agents/pr-verification.agent.md index bcb0aee..d7d8b4b 100644 --- a/.github/agents/pr-verification.agent.md +++ b/.github/agents/pr-verification.agent.md @@ -72,31 +72,67 @@ For each PR to verify: 2. **Read the PR description:** Understand the problem, root cause, and fix approach. 3. **Read any linked issue:** Understand the user-facing scenario that motivated the fix. 4. **Read existing tests in the PR:** Understand what the unit tests and e2e tests - already verify — your sample should complement them, not duplicate them. + already verify. Unit tests and e2e tests verify **internal correctness** of the SDK. + Your verification sample serves a different purpose — it validates that the fix works + under a **realistic customer orchestration scenario**. Do not duplicate existing tests. + Instead, simulate a real-world orchestration workload that previously failed and should + now succeed. Produce a mental model: "Before this fix, scenario X would fail with Y. After the fix, scenario X should succeed with Z." +## Step 2.5: Scenario Extraction + +Before writing the verification sample, extract a structured scenario model from the PR +and linked issue. This ensures the sample is grounded in a real customer use case. + +Produce the following: + +- **Scenario name:** A short descriptive name (e.g., "Fan-out/fan-in with partial activity failure") +- **Customer workflow:** What real-world orchestration pattern does this scenario represent? + (e.g., "A batch processing pipeline that fans out to N activities and aggregates results") +- **Preconditions:** What setup or state must exist for the scenario to trigger? + (e.g., "At least one activity in the fan-out must throw an exception") +- **Expected failure before fix:** What broken behavior would a customer observe before + this fix? (e.g., "The orchestration hangs indefinitely instead of failing fast") +- **Expected behavior after fix:** What correct behavior should a customer observe now? + (e.g., "The orchestration completes with FAILED status and a TaskFailedError containing + the activity's exception details") + +The verification sample must implement this scenario exactly. + ## Step 3: Create Verification Sample -Create a **standalone verification script** that demonstrates the fix works against -a real DTS emulator. The sample should be placed in a temporary working directory. +Create a **standalone verification script** that reproduces a realistic customer +orchestration scenario and validates that the fix works under real SDK usage patterns. +The sample should be placed in a temporary working directory. + +The verification sample is fundamentally different from unit tests or e2e tests: +- **Unit/e2e tests** verify internal SDK correctness using test harnesses and mocks. +- **Verification samples** simulate a real application that an external developer would + write — they exercise the bug scenario exactly as a customer would encounter it, + running against the DTS emulator as a real system test. ### Sample Structure -Create a single TypeScript file that: +Create a single TypeScript file that resembles a **minimal real application**: -1. **Connects to the DTS emulator** using `DurableTaskAzureManagedClientBuilder` / - `DurableTaskAzureManagedWorkerBuilder` with environment variables: +1. **Creates a client and worker** connecting to the DTS emulator using + `DurableTaskAzureManagedClientBuilder` / `DurableTaskAzureManagedWorkerBuilder` + with environment variables: - `ENDPOINT` (default: `localhost:8080`) - `TASKHUB` (default: `default`) -2. **Registers orchestrator(s) and activity(ies)** that exercise the specific - scenario the PR fixes. +2. **Registers orchestrator(s) and activity(ies)** that model the customer workflow + identified in Step 2.5. The orchestration logic should represent a realistic + use case (e.g., a data processing pipeline, an approval workflow, a batch job) + rather than a synthetic test construct. -3. **Schedules the orchestration** and waits for completion. +3. **Starts the orchestration** with realistic input and waits for completion — + exactly as a customer application would. -4. **Prints structured verification output** including: +4. **Validates the final output** against expected results, then prints structured + verification output including: - Orchestration instance ID - Final runtime status - Output value (if any) @@ -108,9 +144,14 @@ Create a single TypeScript file that: ### Sample Guidelines -- Keep it minimal — only the code needed to verify the fix. -- Use descriptive variable/function names that relate to the PR's scenario. -- Add comments explaining what the sample verifies and why. +- The sample must read like **real application code**, not a test. Avoid synthetic + test constructs, mock objects, or test framework assertions. +- Structure the code as a customer would: create worker → register orchestrations → + register activities → start worker → schedule orchestration → await result → validate. +- Use descriptive variable/function names that relate to the customer workflow + (e.g., `processOrderOrchestrator`, `sendNotificationActivity`). +- Add comments explaining the customer scenario and why this workflow previously failed. +- Keep it minimal — only the code needed to reproduce the scenario. - Do NOT import from local workspace paths — use the built packages. - The sample must be runnable with `npx ts-node --swc ` from the repo root. @@ -118,8 +159,14 @@ Create a single TypeScript file that: ```typescript // Verification sample for PR #123: Fix WhenAllTask crash on late child completion -// This sample verifies that whenAll correctly handles fail-fast when one activity -// fails and others complete in the same event batch. +// +// Customer scenario: A batch processing pipeline fans out to multiple activities +// to process data partitions in parallel. If one partition fails, the orchestration +// should fail fast with a clear error instead of hanging indefinitely. +// +// Before fix: The orchestration would hang when a failed activity and a successful +// activity completed in the same event batch. +// After fix: The orchestration correctly fails fast and surfaces the TaskFailedError. import { TaskHubGrpcClient, @@ -174,6 +221,41 @@ main().catch((err) => { }); ``` +## Step 3.5: Checkout the PR Branch (CRITICAL) + +**The verification sample MUST run against the PR's code changes, not `main`.** +This is the entire point of verification — confirming the fix works. + +Before building or running anything, switch to the PR's branch: + +```bash +git fetch origin pull//head:pr- +git checkout pr- +``` + +Then rebuild the SDK from the PR branch: + +```bash +npm ci +npm run build +``` + +Verify the checkout is correct: + +```bash +git log --oneline -1 +``` + +The commit shown must match the PR's latest commit. If it does not, abort +verification for this PR and report the mismatch. + +**After verification is complete** for a PR, switch back to `main` before +processing the next PR: + +```bash +git checkout main +``` + ## Step 4: Start DTS Emulator and Run Verification ### Start the Emulator @@ -199,15 +281,6 @@ sleep 5 # Bash: nc -z localhost 8080 ``` -### Build the SDK - -Ensure the SDK is built so the sample can import from it: - -```bash -npm install -npm run build -``` - ### Run the Sample Execute the verification sample: @@ -319,7 +392,10 @@ If verification **failed**, do NOT update labels. Instead: ### Quality Standards - Verification samples must be runnable without manual intervention. -- Samples must test the **specific scenario** the PR addresses, not generic functionality. +- Samples must reproduce a **realistic customer orchestration scenario** that exercises + the specific bug the PR addresses — not generic functionality or synthetic test cases. +- Samples validate the fix under **real SDK usage patterns**, simulating how an external + developer would use the SDK in production code. - Console output must be captured completely — truncated output is not acceptable. - Timestamps must use ISO 8601 format. diff --git a/.github/workflows/pr-verification.yaml b/.github/workflows/pr-verification.yaml index 781f0f2..e42ff1d 100644 --- a/.github/workflows/pr-verification.yaml +++ b/.github/workflows/pr-verification.yaml @@ -35,17 +35,20 @@ jobs: uses: actions/checkout@v4 with: fetch-depth: 0 + # For pull_request events, this checks out the PR merge commit (includes PR changes). + # For schedule/workflow_dispatch, this checks out main. The agent will + # switch to each PR's branch before building and verifying. - name: ⚙️ Setup Node.js uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VER }} - - name: 📦 Install dependencies - run: npm ci - - - name: 🔨 Build project - run: npm run build + - name: 📦 Install dependencies and build (PR trigger only) + if: github.event_name == 'pull_request' + run: | + npm ci + npm run build - name: 🐳 Start DTS Emulator run: | From 4b70cd736c9ea980fd67de5f0a4bbf1a35f01f33 Mon Sep 17 00:00:00 2001 From: peterstone2017 <12449837+YunchuWang@users.noreply.github.com> Date: Wed, 4 Mar 2026 18:06:36 -0800 Subject: [PATCH 3/3] refactor: streamline PR verification agent by removing unnecessary permissions and updating workflow triggers --- .github/workflows/pr-verification.yaml | 94 +++++++++++++++++++------- 1 file changed, 70 insertions(+), 24 deletions(-) diff --git a/.github/workflows/pr-verification.yaml b/.github/workflows/pr-verification.yaml index e42ff1d..9c07aa2 100644 --- a/.github/workflows/pr-verification.yaml +++ b/.github/workflows/pr-verification.yaml @@ -1,11 +1,11 @@ name: 🔎 PR Verification Agent +# Security: This workflow has write permissions to issues and PRs, so it must NOT +# use the `pull_request` trigger (which checks out untrusted PR code and could +# exfiltrate the job token). Instead, it runs on schedule/manual dispatch only. +# The agent fetches each PR's branch itself before building and verifying. on: - # Trigger when a PR is labeled - pull_request: - types: [labeled] - - # Safety-net: run periodically to catch any missed PRs + # Run periodically to pick up PRs labeled pending-verification schedule: - cron: "0 */6 * * *" # Every 6 hours @@ -19,14 +19,14 @@ permissions: jobs: verify-prs: - # For the labeled trigger, only run when the label is 'pending-verification' - if: >- - github.event_name != 'pull_request' || - github.event.label.name == 'pending-verification' - runs-on: ubuntu-latest timeout-minutes: 30 + # Prevent overlapping runs from racing on label updates / comment posts + concurrency: + group: pr-verification + cancel-in-progress: false + env: NODE_VER: "22" @@ -35,21 +35,13 @@ jobs: uses: actions/checkout@v4 with: fetch-depth: 0 - # For pull_request events, this checks out the PR merge commit (includes PR changes). - # For schedule/workflow_dispatch, this checks out main. The agent will - # switch to each PR's branch before building and verifying. + persist-credentials: false - name: ⚙️ Setup Node.js uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VER }} - - name: 📦 Install dependencies and build (PR trigger only) - if: github.event_name == 'pull_request' - run: | - npm ci - npm run build - - name: 🐳 Start DTS Emulator run: | docker run --name dts-emulator -d --rm -p 8080:8080 \ @@ -68,14 +60,68 @@ jobs: sleep 1 done - - name: 🤖 Run PR Verification Agent - uses: github/copilot-agent@v1 - with: - agent: pr-verification + - name: 🤖 Install GitHub Copilot CLI + run: npm install -g @github/copilot + env: + COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }} + GH_TOKEN: ${{ github.token }} + + - name: 🔎 Run PR Verification Agent + run: | + AGENT_PROMPT=$(cat .github/agents/pr-verification.agent.md) + + FULL_PROMPT=$(cat <&1 || EXIT_CODE=$? + + if [ $EXIT_CODE -eq 124 ]; then + echo "::warning::Agent timed out after 20 minutes" + elif [ $EXIT_CODE -ne 0 ]; then + echo "::warning::Agent exited with code $EXIT_CODE" + fi + + echo "PR verification agent completed." env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }} + GH_TOKEN: ${{ github.token }} ENDPOINT: localhost:8080 TASKHUB: default + CI: "true" + NO_COLOR: "1" + TERM: "dumb" - name: 🧹 Stop DTS Emulator if: always()