From dc5a6aff28a02dbcf954b33ec5f3f2bc6975b4bc Mon Sep 17 00:00:00 2001 From: Matthias Osswald Date: Thu, 17 Sep 2026 09:23:45 +0200 Subject: [PATCH] test(project): Mark dependency content change test as failing Convert the skipped "Build application.a (dependency content changes)" integration test from test.serial.skip to test.serial.failing. Its assertions already encode the desired behavior: a dependency content change should invalidate the application's result cache and trigger a rebuild. It currently fails because the custom task reads dependencies via taskUtil.getProject().getReader(), a path not tracked by the caching system's ResourceRequestManager, so dependency changes do not invalidate the cache. Marking it failing (instead of skipping) keeps CI green while turning the gap into a live signal that flips to a hard error once the behavior is fixed. --- .../ProjectBuilder.customTasks.integration.js | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/packages/project/test/lib/build/ProjectBuilder.customTasks.integration.js b/packages/project/test/lib/build/ProjectBuilder.customTasks.integration.js index ec2855c1293..5cbb1705f21 100644 --- a/packages/project/test/lib/build/ProjectBuilder.customTasks.integration.js +++ b/packages/project/test/lib/build/ProjectBuilder.customTasks.integration.js @@ -236,18 +236,21 @@ test.serial("Build application.a (multiple custom tasks 2)", async (t) => { }); }); -// eslint-disable-next-line ava/no-skip-test -test.serial.skip("Build application.a (dependency content changes)", async (t) => { +test.serial.failing("Build application.a (dependency content changes)", async (t) => { const fixtureTester = new FixtureTester(t, "application.a"); const destPath = fixtureTester.destPath; // Scenario: A custom task reads dependency resources via taskUtil.getProject().getReader() and conditionally // modifies application resources based on what it finds. When the dependency content changes, the application - // should be rebuilt so the custom task can react to the new dependency state. + // should be rebuilt so the custom task can react to the new dependency state. The assertions below encode that + // desired behavior. // - // Currently skipped: The custom task accesses dependencies through taskUtil.getProject("library.d").getReader() - // rather than the monitored "dependencies" reader parameter. Reads through this path are not tracked by the - // caching system's ResourceRequestManager, so dependency changes don't invalidate the application's result cache. + // Marked test.failing because it currently fails: the custom task accesses dependencies through + // taskUtil.getProject("library.d").getReader() rather than the monitored "dependencies" reader parameter. Reads + // through this path are not tracked by the caching system's ResourceRequestManager, so dependency changes don't + // invalidate the application's result cache. AVA reports a failing-marked test as a pass while it throws and as a + // hard error once it starts passing, so committing it keeps CI green and flips to a signal the moment the behavior + // is fixed (at which point drop the `.failing`). // Fixing this requires tracking reads made via taskUtil.getProject().getReader() as dependency requests. // #1 build (no cache, no changes, no dependencies)