Skip to content
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.

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

test_runner: add cwd option to run #54705

Open
wants to merge 19 commits into
base: main
Choose a base branch
from

Conversation

pmarchini
Copy link
Contributor

I'm opening this PR as a draft to have a place where we can discuss this implementation.

Some background context:

During #54225, we discussed the possibility of adding a new option to run.
This new option would be cwd.

This change could impact many other parts of the code, such as:
#54225 (comment)

I just pushed a new commit.

Nice. I realized that this new cwd option may introduce new bugs in at least three places:

For this reason, we decided to work on this in a separate PR (#54225 (comment)).

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/test_runner

@nodejs-github-bot nodejs-github-bot added needs-ci PRs that need a full CI run. test_runner Issues and PRs related to the test runner subsystem. labels Sep 1, 2024
doc/api/test.md Outdated Show resolved Hide resolved
doc/api/test.md Outdated Show resolved Hide resolved
@cjihrig
Copy link
Contributor

cjihrig commented Sep 3, 2024

We need to turn the cwd option into a URL and get the href.

If we make the cwd a part of the globalOptions object, the coverage code will have access to it.

Same thing. The test object there will have a reference to the cwd.

@pmarchini
Copy link
Contributor Author

@cjihrig thanks for the support, I'm gonna take a look ASAP!

doc/api/cli.md Outdated Show resolved Hide resolved
src/node_options.cc Outdated Show resolved Hide resolved
doc/api/cli.md Outdated Show resolved Hide resolved
lib/internal/test_runner/utils.js Outdated Show resolved Hide resolved
src/node_options.h Outdated Show resolved Hide resolved
test/parallel/test-runner-run.mjs Show resolved Hide resolved
@@ -671,6 +671,9 @@ EnvironmentOptionsParser::EnvironmentOptionsParser() {
&EnvironmentOptions::test_coverage_lines,
kAllowedInEnvvar);

AddOption("--experimental-test-cwd",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should add this. The cwd option should be supported by the run() API only IMO.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, makes sense! I was thinking about a way to set the entire test runner's cwd to allow this behavior to be configured via the CLI as well.

Btw, while working on this, I noticed an unexpected behavior related to isolation and watch mode.
I'm going to open a PR to ask for your feedback, @cjihrig

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the user wants to use the CLI, they could do something like cd path/to/tests && node --test

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree

@RedYetiDev RedYetiDev added the commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. label Sep 11, 2024
Comment on lines 568 to 572
if (existsSync(cwd) === false) {
throw new ERR_INVALID_ARG_VALUE('options.cwd', cwd, 'expects an existing directory');
} else if (!lstatSync(cwd).isDirectory()) {
throw new ERR_INVALID_ARG_VALUE('options.cwd', cwd, 'expects a directory, a file was provided');
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather not do this. existsSync() specifically is a race condition. Just assume that the cwd is a directory and handle any errors. For example, the child process APIs, which also take a cwd option don't perform this type of validation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the validation and added a couple of tests to check that run handles an incorrect cwd without throwing errors

@@ -477,7 +477,7 @@ function sortCoverageFiles(a, b) {

function setupCoverage(options) {
let originalCoverageDirectory = process.env.NODE_V8_COVERAGE;
const cwd = process.cwd();
const cwd = options.cwd ?? process.cwd();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should ensure that options.cwd always exists and remove the ?? process.cwd() fallback.

@@ -83,7 +83,7 @@ function createTestTree(rootTestOptions, globalOptions) {
return globalRoot;
}

function createProcessEventHandler(eventName, rootTest) {
function createProcessEventHandler(eventName, rootTest, cwd) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to get the cwd from the rootTest here instead of adding another argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the meantime, I've seen that in harness.js we have:

harness.resetCounters();
globalRoot = new Test({
__proto__: null,
...rootTestOptions,
harness,
name: '<root>',
});
setupProcessState(globalRoot, globalOptions, harness);
globalRoot.startTime = hrtime();
return globalRoot;
}

While the method definition is:

function setupProcessState(root, globalOptions) {
const hook = createHook({

Can I remove harness from the setupProcessState method call, or should I do that in a separate PR?

src/node_options.cc Outdated Show resolved Hide resolved
@pmarchini pmarchini force-pushed the feat/cwd-option-run branch 2 times, most recently from 924c375 to ac74667 Compare September 16, 2024 10:06
@pmarchini pmarchini marked this pull request as ready for review September 16, 2024 13:21
Copy link

codecov bot commented Sep 16, 2024

Codecov Report

Attention: Patch coverage is 83.33333% with 3 lines in your changes missing coverage. Please review.

Project coverage is 88.41%. Comparing base (89a2f56) to head (e0b7a48).
Report is 5 commits behind head on main.

Files with missing lines Patch % Lines
lib/internal/test_runner/runner.js 78.57% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #54705      +/-   ##
==========================================
+ Coverage   88.39%   88.41%   +0.02%     
==========================================
  Files         652      652              
  Lines      186565   186571       +6     
  Branches    36046    36047       +1     
==========================================
+ Hits       164916   164963      +47     
+ Misses      14908    14880      -28     
+ Partials     6741     6728      -13     
Files with missing lines Coverage Δ
lib/internal/test_runner/coverage.js 64.69% <100.00%> (-0.06%) ⬇️
lib/internal/test_runner/harness.js 92.67% <100.00%> (+0.02%) ⬆️
lib/internal/test_runner/runner.js 89.42% <78.57%> (+2.38%) ⬆️

... and 32 files with indirect coverage changes

Comment on lines 93 to 96
const interval = setInterval(() => renameSync(fileToRenamePath, newFileNamePath), common.platformTimeout(1000));
const interval = setInterval(() => {
renameSync(fileToRenamePath, newFileNamePath);
clearInterval(interval);
}, common.platformTimeout(1000));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @cjihrig, regarding these tests, I was working on a GitHub codespace yesterday, and I noticed that this test was flaky there.
The issue was with the interval: if the system is delayed for any reason beyond the timeout, a second run of "rename" (and similarly for "delete") is triggered, causing an error because the file has already been renamed and can no longer be found under its previous name.

I'll take a look at the other similar tests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense. Timers in tests should be avoided like the plague if possible.

Do we need to use an interval for operations like that? For example, would it work to use a setTimeout() and then reschedule the callback again once the timer fires?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @cjihrig, I agree, I hadn’t thought about replacing it with setTimeout 😬
I’ll do it ASAP !

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cjihrig, following another fix I was working on for a related flaky test, test/parallel/test-runner-watch-mode-complex.mjs, and following your suggestions, I removed the setIntervals in an attempt to simplify the test's readability while hopefully preventing flakiness

Comment on lines 40 to 41
...(cwd ? { cwd } : {}),
...(isolation ? { isolation } : {}),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be simplified to:

Suggested change
...(cwd ? { cwd } : {}),
...(isolation ? { isolation } : {}),
cwd,
isolation,

@@ -29,6 +29,10 @@ import('data:text/javascript,');
test('test has ran');`,
};

function wait(ms) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use setTimeout() from node:timers/promises (or is this just the changes from your other PR?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Absolutely! I worked on them at the same time.
I need to port what we did on the other test to this one 😁

This change could also reduce the flakiness of this test (at least I hope so)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -252,7 +252,11 @@ function lazyBootstrapRoot() {
__proto__: null,
entryFile: process.argv?.[1],
};
const globalOptions = parseCommandLine();
const globalOptions = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it would be more efficient to either:

  1. Add cwd to the object returned in parseCommandLine(). Although then that function is not strictly only working with the command line.
  2. Do globalOptions.cwd = process.cwd() here instead of creating an object in parseCommandLine(), spreading it here, and creating a new object containing all the same values as the original object.

I'm personally leaning toward option 2.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey @cjihrig, I agree regarding option 2.
IMHO option 1 would make sense if we were adding a new option.

I'm going to take a look ASAP

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@mcollina mcollina added the request-ci Add this label to start a Jenkins CI on a PR. label Sep 23, 2024
@cjihrig cjihrig added the request-ci Add this label to start a Jenkins CI on a PR. label Sep 24, 2024
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Sep 24, 2024
@nodejs-github-bot
Copy link
Collaborator

@cjihrig
Copy link
Contributor

cjihrig commented Sep 24, 2024

It looks like there may be relevant failures in the latest CI run.

@pmarchini
Copy link
Contributor Author

It looks like there may be relevant failures in the latest CI run.

Hey @cjihrig, yes I've seen, I'm preparing my Windows build!

@pmarchini
Copy link
Contributor Author

@cjihrig after some attempts I was able to reproduce the same errors on my Windows 10 machine.
I'll take a look ASAP, it's definitely flaky

@pmarchini
Copy link
Contributor Author

@cjihrig, I'm still looking into this. I've been able to replicate it 3 times in 12 hours, after thousands of retries

@pmarchini
Copy link
Contributor Author

pmarchini commented Sep 26, 2024

Hey @cjihrig, I have just pushed a debug-only commit, I will revert it later.

In my local Windows environment, something very strange is happening:

The error, like the one we see in the pipeline, occurs only when running the test on a machine that has just been restarted from sleep.
It makes me think there might be some correlation with my very slow disk and the recovery from sleep mode.

What surprises me is that, looking at the stack trace, it seems that the origin of the error is the same abort triggered in the unit test after the test:watch:drained (EDIT: this is expected).

While I keep testing, I will need another pipeline run.
(I don't like trying to debug using the CI, but I'm not finding another way)

WDYT?

@cjihrig
Copy link
Contributor

cjihrig commented Sep 28, 2024

WDYT?

I don't have a great answer. This is why I try to avoid working on watch mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. needs-ci PRs that need a full CI run. test_runner Issues and PRs related to the test runner subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants