-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
build: fail on CI if leftover processes #11269
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rubber-stamp LGTM... tho someone with better Makefile
kung-fu should also review
Makefile
Outdated
endif | ||
clear-stalled: | ||
ps awwx | grep Release/node | grep -v grep | cat | ||
ps awwx | grep Release/node | grep -v grep | awk '{print $$1}' | $(XARGS) kill |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there are no node processes won't this result in calling kill with no argument which will then print out usage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mhdawson If it did, the CI run for this would have failed hard!
On AIX and OS X (which have BSD-based xargs
), empty stdin is a no-op so kill
is not called. On all others in CI (which have GNU-based xargs
), we add -r
(a few lines above) which causes the same behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Whoops, CI hasn't run for this. I was thinking of #11246 which contains these identical lines.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok thanks for the clarification. I think I ran the command on linux but without the -r
Makefile
Outdated
$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \ | ||
--mode=release --flaky-tests=$(FLAKY_TESTS) \ | ||
$(TEST_CI_ARGS) $(CI_JS_SUITES) | ||
! ( ps awwx | grep Release/node | grep -v grep ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to print out the info on what's still running here and then cleanup. This will leave them running until the next ci run right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mhdawson Yes, that's probably a better approach. I'll try to learn enough about make
to figure out how to do that. :-D
Took me a while to work out that this "Depends on #11246" because it's a one line change on top of it (of the two commits, the first one is #11246). Is there a reason to do this as a separate PR? I still think that if this was done in |
Mostly so the other PR containing minimum required functionality can land as soon as possible and prevent spurious CI failures at the earliest possible time. Trying to put this post-run stuff into that other PR would mean the stuff in that other PR (that is IMO ready-to-go, at least as a stopgap measure) would have to wait until we resolve whether/how this post-run stuff should terminate processes it find, feasibility of putting it in |
48693fc
to
c5051e4
Compare
OK, the other PR landed, so this one now has a cleaner and shorter diff and I am ready to discuss colors for the bike shed!!!! :-D |
c5051e4
to
5589bd8
Compare
On the suggestion that in addition to failing if there are leftover processes, terminate those processes... seems appealing, but as I look at doing it, I'm starting to feel pretty YAGNI about it:
I'm inclined to leave this reporting/failing bit as is and save the terminate-the-processes for a future enhancement if we find we really need it. (Like I said, we lose the ability to inspect the processes if we go that route, so maybe we don't want to do that after all?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with this change going in and termination being handled in a follow on if we agree we want to do it.
We run a bunch of other tests on the machines (e.g. citgm tests, node-report tests, manually running individual tests). Clearing up at the start is a good way to make sure our test runs pass properly, but clearing up at the end is IMHO the right thing to do as users of a shared CI.
Did you try doing it in
I've never done anything with a process other than look at it with However, if you implemented this in |
Makefile
Outdated
@@ -223,13 +223,15 @@ test-ci-js: | clear-stalled | |||
$(PYTHON) tools/test.py $(PARALLEL_ARGS) -p tap --logfile test.tap \ | |||
--mode=release --flaky-tests=$(FLAKY_TESTS) \ | |||
$(TEST_CI_ARGS) $(CI_JS_SUITES) | |||
! ( ps awwx | grep Release/node | grep -v grep ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question. Are all these flags portable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure they're all used in #11246, so if they aren't we should find out pretty quickly 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, they're all portable, or at least sufficiently portable that they work on all the non-Windows CI machines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool then.
If any tests leave processes running after testing results are complete, fail the test run.
5589bd8
to
db5c314
Compare
This will now both fail if there are leftover processes and try to clean them up. PTAL (If anyone wants to move it into |
@nodejs/build |
Landed in 189b49a |
If any tests leave processes running after testing results are complete, fail the test run. PR-URL: nodejs#11269 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
If any tests leave processes running after testing results are complete, fail the test run. PR-URL: #11269 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
If any tests leave processes running after testing results are complete, fail the test run. PR-URL: #11269 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
If any tests leave processes running after testing results are complete, fail the test run. PR-URL: #11269 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
If any tests leave processes running after testing results are complete, fail the test run. PR-URL: #11269 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
If any tests leave processes running after testing results are complete, fail the test run. PR-URL: #11269 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Santiago Gimeno <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Johan Bergström <[email protected]>
If any tests leave processes running after testing results are complete, fail the test run.
Dependent on #11246
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
build test