fix(unit-only): include harness Dockerfile content in deploy hash (#1380)

[aidandaly24]

Refs aws#1380

Issues

• Change detection skips Dockerfile changes in dev mode aws/agentcore-cli#1380 — For a preview-gated, harness-only project whose harness references a custom Dockerfile, editing only the Dockerfile's contents (not its name) does not change the project deploy hash, so agentcore deploy/agentcore dev reports "No changes detected — skipping deploy" and the cloud AWS::BedrockAgentCore::Harness keeps running the previously-built container image. The user must touch harness.json (or any other hashed input) to force a redeploy.

Root cause

computeProjectDeployHash (change-detection.ts:14-43) hashes harness.json (line 26) + system-prompt.md (line 32) + aws-targets.json + projectSpec, but never reads the harness Dockerfile content. harness.json stores only the Dockerfile filename (HarnessPrimitive.ts:256), so a content-only edit leaves the hash unchanged; canSkipDeploy (change-detection.ts:52-75, runtimes-length guard at line 56) returns true and short-circuits handleDeploy at useDevDeploy.ts:76-80 and progress.ts:56-62. Note: the brief's cited CDK construct AgentCoreHarnessEnvironment.ts does NOT exist in CDK alpha.19 — harness synth (which passes hasDockerfile/dockerfile/codeLocation to drive the container build) is in the CLI's vended src/assets/cdk/lib/cdk-stack.ts + bin/cdk.ts:102-104 via @aws/agentcore-cdk HarnessDeploymentConfig. Owner is still CLI.

The fix

In computeProjectDeployHash, after hashing each harness.json, parse it and when harnessSpec.dockerfile is set, readFile the Dockerfile from the harness dir (join(harnessDir, harnessSpec.dockerfile)) and hash.update its content inside a try/catch so a missing file degrades gracefully. Extend change-detection.test.ts (whose readFile mock currently returns only harness.json/system-prompt.md) to mock a Dockerfile and assert a content-only Dockerfile change produces a different hash. This is exactly what open PR aws#1587 ('fix: include harness Dockerfiles in deploy hash', +13 in change-detection.ts, +36/-4 in change-detection.test.ts) implements; it just needs to land.

Files touched: /local/home/aidandal/workplace/issues/agentcore-cli/src/cli/operations/deploy/change-detection.ts (computeProjectDeployHash, harness loop lines 23-37) plus /local/home/aidandal/workplace/issues/agentcore-cli/src/cli/operations/deploy/tests/change-detection.test.ts. Tracked by open PR aws#1587 (branch fix/harness-dockerfile-deploy-hash).

Validation evidence

The fix was verified by reproducing the original symptom and re-running after the change:

BEFORE (pre-fix code from HEAD, no dockerfile refs): the new unit test 'returns different hash when only the referenced Dockerfile content changes' FAILS — computeProjectDeployHash returns the IDENTICAL hash 6f2f6e5023805fe7 for harness.json {"name":"h1","dockerfile":"Dockerfile"} when only the Dockerfile body changes from 'FROM python:3.12' to 'FROM python:3.13'. AssertionError: expected '6f2f6e5023805fe7' not to be '6f2f6e5023805fe7'. This is the root cause of the reported symptom: a content-only Dockerfile edit leaves the deploy hash unchanged, so canSkipDeploy returns true and the CLI prints 'No changes detected — skipping deploy', leaving the old container running. AFTER (fix/1380 working tree, change-detection.ts reads dockerfile = JSON.parse(harnessJson)?.dockerfile and hashes readFile(join(harnessDir, dockerfile)) under try/catch inside the harness loop): the same test PASSES — hash1 !== hash2. The no-dockerfile-field cases ('returns same hash for same inputs', '16-char hex') still produce stable hashes (graceful degradation via the if(dockerfile) guard + try/catch). Targeted file change-detection.test.ts: 10/10 pass with fix vs 1 fail (9 pass) on pre-fix code, isolating the symptom to exactly the Dockerfile-content scenario.

Test suite: green.

---

Staged on the fork as a draft for human review. Promote to aws/agentcore-cli after vetting.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	37.17%	13598 / 36582
🔵	Statements	36.44%	14457 / 39672
🔵	Functions	31.8%	2333 / 7336
🔵	Branches	31.11%	9002 / 28934

Generated in workflow #90 for commit 696b56b by the Vitest Coverage Report Action