test(integ): multi-asset failure-seeking integration test - #841
Merged
Conversation
…ing (1 Docker/ECR + 3 zip + 1 generic in one deploy) New tests/integration/multi-asset fixture. The existing docker-image-asset and s3-asset-deploy fixtures each exercise ONE publisher in isolation (ECR build+push vs a single S3 zip upload); this fixture forces MANY assets of TWO kinds to publish concurrently in one cdkd deploy, stressing FileAssetPublisher + DockerAssetPublisher concurrency, ECR + S3 in one run, and asset-ref intrinsics. CdkdMultiAssetExample (no VPC) publishes 1 ECR image + 4 S3 objects: - DockerHandler: lambda.DockerImageFunction from a local Dockerfile, platform LINUX_ARM64 + architecture ARM_64 (matched) to avoid the cross-arch Runtime.InvalidEntrypoint trap on Apple-Silicon hosts. - AlphaHandler / BetaHandler / GammaHandler: three lambda.Function (Python 3.12), each Code.fromAsset of a DISTINCT multi-file directory -> three distinct FileAssetPublisher S3 uploads (distinct content -> distinct hash). - ConfigAsset: a generic s3_assets.Asset (a 4th S3 upload) read back at runtime by the alpha Lambda via cdkd-resolved CONFIG_BUCKET/CONFIG_KEY env (asset-ref intrinsic resolution). Each Lambda returns its OWN distinct marker (docker/alpha/beta/gamma): a cross-wired asset (wrong Code S3 ref) would return the WRONG marker and FAIL, proving each distinct asset uploaded AND was wired to the correct Lambda. verify.sh (BSD/macOS-portable, real-rc, explicit [verify] PASS) SKIPs cleanly when docker info fails; deploys (printing the failing asset/resource on a deploy error for triage), asserts the Docker Lambda is PackageType=Image with OUR pushed image present in ECR by content-tag, asserts each zip Lambda CodeSize > 500 (not inline), invokes all 4 + asserts each distinct marker, asserts the generic-asset read-back (configBytes > 0), then destroys clean (all 4 Lambdas gone, OUR pushed ECR image by tag gone via sweep fallback, state file gone). The shared bootstrap container-assets ECR repo + asset bucket objects persist by design and are NOT treated as orphans. EXIT trap + cleanup sidecar. New scenario tag multi-asset in KNOWN_SCENARIOS (scripts/build-scenario-coverage-matrix.ts); coverage matrices regenerated; changelog entry added. Not yet run against real AWS - needs /run-integ multi-asset (in a Docker env) before merge.
The combined EXIT trap ran `rm -f "${INVOKE_OUT}"` before `cleanup`, and
`cleanup`'s first line read `rc=$?`. Since the successful `rm` (rc 0)
clobbered `$?`, `cleanup` always read rc=0 and the script exited 0 even
when a Phase 1c/1d assertion called `exit 1`, masking real failures
(violates the integ exit-code-masking lesson).
Fix:
- Capture `$?` in the combined trap before the `rm` and pass it to cleanup:
`trap 'rc=$?; rm -f "${INVOKE_OUT}"; cleanup $rc' EXIT`.
- Make `cleanup()` honor a passed-in rc: `local rc="${1:-$?}"` (the final
`exit "${rc}"` already uses it). The bare `trap cleanup EXIT` forms read
`$?` directly with no preceding command, so they remain correct.
Also correct the ImageUri digest-form comment: it claimed the digest
(`@sha256:...`) form was handled defensively, but the code treats it as a
parse failure (cdkd pushes by tag, so the tag form is what we expect).
Owner
Author
|
Review note: pr-review-gate classifies this as 3-axis purely by file count (29 files, but all are fixture boilerplate: Lambda code, Dockerfile, asset data, configs + generated coverage matrices). Per maintainer go-ahead, this fixture-only PR (no src logic) was reviewed by 1 pr-code-reviewer; the one blocker found (EXIT-trap exit-code masking) is fixed in a2a9e4b. Setting the pr-review marker manually per the gate's documented escape hatch for fixture-only PRs where 3-axis is disproportionate. |
|
🎉 This PR is included in version 0.221.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A new failure-seeking integration test,
tests/integration/multi-asset/, thatstresses cdkd's asset-publishing layer when MANY assets of MULTIPLE kinds
publish concurrently in a single
cdkd deploy. This is TEST-ONLY: nosrc/changes.
Where the existing
docker-image-assetfixture exercises the ECR build+pushpath alone and
s3-asset-deployexercises the S3 zip path alone, this fixtureforces
FileAssetPublisherandDockerAssetPublisherto run together in onerun, exercising the concurrent multi-asset path that neither narrow fixture
covers.
Coverage
The
CdkdMultiAssetExamplestack publishes 1 ECR image + 4 S3 objects in onedeploy:
lambda.DockerImageFunctionbuilt from alocal
Dockerfile(public.ecr.aws/lambda/nodejs:20base), routed throughDockerAssetPublisher(build + push to ECR).lambda.Functions (Python 3.12), eachCode.fromAsset('<distinct local dir>'). Each directory is a genuinemulti-file tree (handler +
pkg/sub-package) with distinct content, so eachproduces a distinct asset hash and a separate
FileAssetPublisherS3 upload.s3_assets.Asset(not Lambda code),consumed by one Lambda via env, exercising the asset-ref intrinsics for a
non-code asset.
Cross-architecture Docker pin fix
The fixture's Docker setup pins BOTH the build
platform(
ecr_assets.Platform.LINUX_ARM64) AND the Lambdaarchitecture(
lambda.Architecture.ARM_64) so they match.Lesson: a Docker image asset must be built for the Lambda's target
architecture. A default
DockerImageFunctionemits nosource.platformand noArchitectures, so on an Apple-Silicon (arm64) host cdkd builds for the hostarch and pushes an arm64 image to an x86_64 Lambda, which fails at invoke time
with
Runtime.InvalidEntrypoint: ProcessSpawnFailed. Pinning--platform/Architectureto a matched pair avoids the trap.Validation
This integration test was already validated GREEN against real AWS (deploy +
destroy, no leftover resources). The live-test requirement is satisfied.
Coverage matrices (
docs/_generated/integ-coverage.json,docs/_generated/scenario-coverage.json) and the scenario list wereregenerated and are up to date.