[so0k]

Description

Same class of bug as #474, in a package it did not cover. Nx restores only a target's declared outputs on a cache hit, and Depot runners serve remote hits for the build targets.

The edge provider bindings were a postbuild side effect of @cdktn/provider-generator's build, written to edge-provider-bindings/, which the shared default outputs do not cover. On a cache hit the directory stayed empty, the integration prepare job uploaded nothing (No files were found with the provided path: packages/@cdktn/provider-generator/edge-provider-bindings), and every linux_integration job failed with Artifact not found for name: edge-provider-bindings. Seen on every integration matrix job of #478 (https://github.com/open-constructs/cdk-terrain/actions/runs/37799770873). The Release workflow is not affected because its prepare jobs run on ubuntu-latest; the PR integration prepare job runs on a Depot runner.

Following review, the bindings now come from their own cached target instead of a postbuild hook:

• build:edge-bindings on @cdktn/provider-generator depends on build, declares edge-provider-bindings/ as its output, and names src/__tests__/edge-provider-schema/** as an input alongside production and ^production. Moving it out of postbuild also keeps the five-language jsii-pacmak run off every local pnpm build.
• A root build:edge-bindings script runs it, and the three prepare jobs (integration.yml, both release.yml prepare jobs) call it after pnpm run package, right before the upload.
• if-no-files-found: error on the three edge-bindings uploads (integration.yml and both release.yml prepare jobs), so an empty upload fails the prepare job and the matrix is skipped instead of every job failing on download.
• test/package.json's edge:install runs the target before copying, so the documented local flow (pnpm package, then pnpm integration) and cd test && pnpm edge:install keep working; test/Readme.md describes it.
• @cdktn/provider-generator's build target adds the edge schema sources to its inputs, so the compiled generator can never come from a cache entry older than the sources the bindings target hashes (review finding by @sakul-learning and @jsteinich).

The cdktn-cli output declaration from the first revision moved to #485, since making bundle/ cacheable needs its own inputs fixed first.

Verification

In a clean worktree with Nx 22.7.9:

• Fresh pnpm run build:edge-bindings generates edge-provider-bindings/{csharp,go,java,python,providers}.
• Deleting the directory and re-running is a cache hit that restores it.
• Appending to src/__tests__/edge-provider-schema/builder.ts re-runs build:edge-bindings while the upstream builds stay cached.
• pnpm run edge:install from test/ builds the chain, generates the five language directories and copies them into test/edge-provider-bindings.

One observation from that testing: in this repo the negative patterns in the production named input do not exclude anything from task hashes. Editing a test file in @cdktn/commons re-runs its build, and spelling the exclusion several ways changes nothing, while a positive-only input list behaves correctly. So the stale-bindings scenario could not have occurred as described, because any __tests__ edit already invalidates build. The explicit input on the new target keeps that true by declaration. The broader effect, every test edit rebuilding every package, is pre-existing and not addressed here.

Integration is left enabled on this PR so the Depot-runner prepare job demonstrates the artifact uploading again.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have performed a self-review of my code
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings

🤖 Generated with Claude Code

https://claude.ai/code/session_01RvtnNBvNuTHU4dG3NFuBeb

[sakul-learning]

Two findings remain at de717d03:

1. The normal local integration commands no longer produce the edge bindings they immediately copy. packages/@cdktn/provider-generator/package.json removes the postbuild generator, but root package.json still starts both integration and integration:update with test/package.json → edge:install, whose first operation copies packages/@cdktn/provider-generator/edge-provider-bindings. That directory is generated and untracked, so after the documented clean flow in CONTRIBUTING.md (pnpm package followed by pnpm integration, or pnpm integration:update) the copy source does not exist and the command fails before Jest starts. test/Readme.md documents a new manual step, but the primary contributor instructions and executable scripts still retain the old contract. Please make edge:install or the root integration scripts invoke the cached build:edge-bindings target before copying, and update the main contributor workflow if a separate prerequisite is intentionally required.

2. The new cache target hashes the edge-schema source but executes compiled output supplied by a separately cached target whose declared inputs exclude that source. build:edge-bindings lists src/__tests__/edge-provider-schema/** in its own inputs, depends on build, and runs node ./build/__tests__/edge-provider-schema/cli.js. The dependency has an independent cache key inherited from nx.json: build.inputs = ["production", "^production"], while production excludes **/__tests__/**. Under the declared Nx contract, changing builder.ts invalidates build:edge-bindings but can leave @cdktn/provider-generator:build cached, causing the rerun to execute the previous compiled CLI and regenerate stale bindings. The observed Nx 22.7.9 behavior where the negative patterns currently fail to exclude test files masks this path, but relying on that bug makes the target fragile if the exclusions begin working as configured or after an Nx upgrade. Please make the compilation dependency explicit too—for example, override the provider-generator build inputs to include the edge-schema sources, or compile/run the edge generator in a target whose cache inputs cover the source it executes.

The current CI integration path itself is wired correctly: it ran build:edge-bindings, uploaded the 816,516-byte artifact, and the integration matrix passed. The concerns are the clean local workflow and the durability of the two-target cache contract.

[jsteinich]

Thanks for moving the bindings into their own target. CI looks good. I agree with the two findings @sakul-learning left on #485; both are about code in this PR:

1. Local integration runs lose the bindings. Root integration and integration:update start with edge:install, which copies packages/@cdktn/provider-generator/edge-provider-bindings. With postbuild gone, nothing creates that directory, so the documented flow (pnpm package, then pnpm integration) fails before Jest starts. Prefixing both root scripts with pnpm run build:edge-bindings && would fix it, and a cache hit makes the extra step nearly free. CLAUDE.md and .claude/skills/test-audit/TIERS.md also still describe the old steps.

2. build:edge-bindings can run a stale cli.js. The target hashes src/__tests__/edge-provider-schema/**, but it runs build/__tests__/edge-provider-schema/cli.js, which comes from build, and build inherits production (which excludes __tests__). You found that the negations don't take effect today, so this is latent. Still, an Nx upgrade or a fix to the named input would expose it. Adding {projectRoot}/src/__tests__/edge-provider-schema/** to provider-generator's build inputs makes it explicit.

Minor: the two edge-binding uploads in release.yml (edge-provider-bindings-release, edge-provider-bindings-next) didn't get the if-no-files-found: error that integration.yml got.

[so0k]

Thanks both, addressed in c9dbd23:

1. Local flow. test/package.json's edge:install now runs the root build:edge-bindings script before copying, so pnpm package then pnpm integration works as CONTRIBUTING and CLAUDE.md document it, and cd test && pnpm edge:install from the test-audit TIERS.md and the edge:update pre-hook keep working too. I put the call there rather than in the root integration scripts so every path that copies the directory also produces it; a warm cache makes the extra step free. The manual step I had added to test/Readme.md is gone again. Verified locally: pnpm run edge:install from test/ builds the chain, generates the five language directories and copies them.
2. Cache contract. @cdktn/provider-generator's build target now overrides its inputs to add {projectRoot}/src/__tests__/edge-provider-schema/**, so a generator edit invalidates the compilation as well as the bindings target by declaration, independent of the negation behaviour observed today.
3. The two release.yml edge uploads now have if-no-files-found: error like integration.yml.

#485 is rebased on top.

[jsteinich]

Thanks, all three points are addressed. Building the bindings from edge:install covers every path that copies them, and CI never calls it.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.