Skip to content

test(project): Mark dependency content change test as failing #1599

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
matz3 merged 1 commit into from
Sep 21, 2026
Merged

test(project): Mark dependency content change test as failing #1599

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions packages/project/test/lib/build/ProjectBuilder.customTasks.integration.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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)
Expand Down
Loading