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

Appveyor build is flaky #9533

Closed
not-an-aardvark opened this issue Oct 29, 2017 · 9 comments · Fixed by #9588
Closed

Appveyor build is flaky #9533

not-an-aardvark opened this issue Oct 29, 2017 · 9 comments · Fixed by #9588
Assignees
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion bug ESLint is working incorrectly build This change relates to ESLint's build process

Comments

@not-an-aardvark
Copy link
Member

For the past few weeks, the Appveyor build has been occasionally been failing with messages like this:

It's not clear what's going on. (It says "no coverage files found", but I'm not sure why that's the case, or why it only happens sometimes.)

@not-an-aardvark not-an-aardvark added accepted There is consensus among the team that this change meets the criteria for inclusion bug ESLint is working incorrectly build This change relates to ESLint's build process labels Oct 29, 2017
@not-an-aardvark
Copy link
Member Author

The "ERROR: no coverage files found" message occurs when this command is run and no coverage/ folder was generated by the above command. However, I'm not sure why that would be happening.

@aladdin-add
Copy link
Member

aladdin-add commented Nov 6, 2017

it happened occasionally and I've never seen it in my local, so I guess it might be related to mocha timeout. can we set it to be bigger to see if it happens again?

@not-an-aardvark
Copy link
Member Author

not-an-aardvark commented Nov 7, 2017

I noticed that the error usually happens when the progress bar is at this stage:

[▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬..]

I think that's the point where the tests in tests/bin/eslint.js tests run. It makes sense that the tests/bin/eslint.js tests could be causing the problem, because:

  • Those tests use child_process.fork(), which could have odd side-effects
  • Those tests take longer than other tests

@not-an-aardvark
Copy link
Member Author

I don't think the issue is a timeout, because when I apply this diff:

diff --git a/tests/bin/eslint.js b/tests/bin/eslint.js
index 7742eb71..830672e5 100644
--- a/tests/bin/eslint.js
+++ b/tests/bin/eslint.js
@@ -46,7 +46,9 @@ function getOutput(runningProcess) {
     return awaitExit(runningProcess).then(() => ({ stdout, stderr }));
 }
 
-describe("bin/eslint.js", () => {
+describe("bin/eslint.js", function() {
+    this.timeout(200); // eslint-disable-line no-invalid-this
+
     const forkedProcesses = new Set();
 
     /**

...I get a bunch of error messages that the test timed out. On Appveyor, there are no error messages.

@not-an-aardvark
Copy link
Member Author

It's also interesting that the test bar stops at [▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬..] and it never reaches the end, and then the "ERROR: no coverage files found" is printed immediately afterwards. Under normal circumstances, a coverage/ folder is created after the tests finish, and then istanbul check-coverage is run to verify the coverage. If the coverage folder doesn't have any coverage info yet (e.g. because the tests are still running), then istanbul will output "ERROR: no coverage files found".

So my guess is that when we do child_process.fork() in tests/bin/eslint.js and then the forked process stops, somehow that is getting interpreted as if the parent test process stopped, so the Makefile.js script continues even though the tests haven't finished.

@not-an-aardvark not-an-aardvark self-assigned this Nov 7, 2017
not-an-aardvark added a commit that referenced this issue Nov 7, 2017
This removes the `shelljs-nodecli` module from the build process.
`shelljs-nodecli` relies on a very old version of the `shelljs` module,
which might be causing a flaky build on Appveyor (see
#9533 for details). In any case,
removing `shelljs-cli` seem to make `npm test` run 40% faster anyway, so
it should be an improvement even if it doesn't fix the Appveyor build.
aladdin-add pushed a commit that referenced this issue Nov 7, 2017
This removes the `shelljs-nodecli` module from the build process.
`shelljs-nodecli` relies on a very old version of the `shelljs` module,
which might be causing a flaky build on Appveyor (see
#9533 for details). In any case,
removing `shelljs-cli` seem to make `npm test` run 40% faster anyway, so
it should be an improvement even if it doesn't fix the Appveyor build.
@not-an-aardvark
Copy link
Member Author

Looks like this is still a problem (e.g. the build failed for #9589)

@not-an-aardvark
Copy link
Member Author

Should this be closed? I haven't seen the build fail for awhile.

@ilyavolodin
Copy link
Member

I think it's fine to close it. Occasional errors in the build happens. We've had them on Travis during last release, for example. I don't think there a way to completely eliminate them. As long as they are within reasonable boundaries, we just have to live with them.

@aladdin-add
Copy link
Member

a timeout error was happening today. https://ci.appveyor.com/project/nzakas/eslint/build/9677

@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Jun 14, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion bug ESLint is working incorrectly build This change relates to ESLint's build process
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants