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

New CI job to stress a single test #3854

Closed
joaocgreis opened this issue Nov 16, 2015 · 8 comments
Closed

New CI job to stress a single test #3854

joaocgreis opened this issue Nov 16, 2015 · 8 comments
Labels
test Issues and PRs related to the tests.

Comments

@joaocgreis
Copy link
Member

@nodejs/collaborators

https://ci.nodejs.org/job/node-stress-single-test/ is now available and ready to use. It can be used to help determining if a test is flaky or not.

To test a pull request, use refs/pull/99999/head in the GIT_REMOTE_REF field.

The default of 100 runs can be useful to get the error output of a test that fails frequently, or to quickly test a fix attempt before a longer test. To know with a high probability that a test is not flaky I suggest 10000 runs, because I've seen a flaky test failing about 3 out of 10000 runs. For now these are just suggestions, we can change the default and create best practices when we have more experience with this.

@joaocgreis joaocgreis added the test Issues and PRs related to the tests. label Nov 16, 2015
@jasnell
Copy link
Member

jasnell commented Nov 16, 2015

+1! Awesome to see. Thank you!
On Nov 16, 2015 5:25 AM, "João Reis" notifications@github.com wrote:

@nodejs/collaborators https://github.com/orgs/nodejs/teams/collaborators

https://ci.nodejs.org/job/node-stress-single-test/ is now available and
ready to use. It can be used to help determining if a test is flaky or not.

To test a pull request, use refs/pull/99999/head in the GIT_REMOTE_REF
field.

The default of 100 runs can be useful to get the error output of a test
that fails frequently, or to quickly test a fix attempt before a longer
test. To know with a high probability that a test is not flaky I suggest
10000 runs, because I've seen a flaky test failing about 3 out of 10000
runs. For now these are just suggestions, we can change the default and
create best practices when we have more experience with this.


Reply to this email directly or view it on GitHub
#3854.

@Fishrock123
Copy link
Contributor

Wow, nice job @joaocgreis!

@cjihrig
Copy link
Contributor

cjihrig commented Nov 16, 2015

This is cool! Please don't take me closing the issue as thinking otherwise :-)

@cjihrig cjihrig closed this as completed Nov 16, 2015
@Trott
Copy link
Member

Trott commented Nov 16, 2015

This is great, and I'm using this RIGHT NOW to determine one test's flaky-or-not status. Thanks!

Super-minor nit: 9999 is easier to read and type than 10000, so maybe recommend that in the tiny text beneath the box for RUN_TIMES?

@joaocgreis
Copy link
Member Author

Thanks!

@Trott fixed!

@jasnell
Copy link
Member

jasnell commented Nov 18, 2015

@joaocgreis .. how difficult do you think it would be to create a variation on this that is essentially a combination of node-test-pull-request and node-stress-single-test. For Pull-Requests that make test changes, it would be nice to be able to do a node-test-pull-request and stress test all at once (see: #3758 (comment) and subsequent comments)

@joaocgreis
Copy link
Member Author

@jasnell that would involve changing all the test-commit jobs. A lot of jenkins clicking, but quite doable. The problem I see would be to include it in the TAP output. The best thing would be to stress the test with test.py, running it along with other tests as I described in nodejs/build#260 (comment) .

@jasnell
Copy link
Member

jasnell commented Nov 18, 2015

OK, good to know. I'll add it to my list of things to investigate when I
get a bit more time
On Nov 18, 2015 10:12 AM, "João Reis" notifications@github.com wrote:

@jasnell https://github.com/jasnell that would involve changing all the
test-commit jobs. A lot of jenkins clicking, but quite doable. The problem
I see would be to include it in the TAP output. The best thing would be to
stress the test with test.py, running it along with other tests as I
described in nodejs/build#260 (comment)
nodejs/build#260 (comment) .


Reply to this email directly or view it on GitHub
#3854 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
test Issues and PRs related to the tests.
Projects
None yet
Development

No branches or pull requests

5 participants