-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Add tc39/test262 tests in k6 #1747
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1747 +/- ##
==========================================
+ Coverage 71.40% 71.47% +0.06%
==========================================
Files 178 178
Lines 13751 13777 +26
==========================================
+ Hits 9819 9847 +28
+ Misses 3320 3317 -3
- Partials 612 613 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
This reverts commit c5ab1f0.
.github/workflows/all.yml
Outdated
@@ -83,6 +83,28 @@ jobs: | |||
fi | |||
go test "${args[@]}" -timeout 800s ./... | |||
|
|||
tc39: | |||
runs-on: ubuntu-latest | |||
steps: |
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.
Do we want to run this on every commit? We might be OK with just running them on each release (version tag), especially if they're flaky, and we should probably exclude it from the requirements for a successful build.
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.
- there are currently no requirements (I think)
- they aren't really flaky ... just they sometimes take too much time - predomenantly when I increase them or decide to try to enable parallel execution ... OR maybe they take too much memory 🤷♂️
- In the end we might move them to not being run on eveyr commit :D, but currently they are in development :P
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.
We can move this to its own job, and have it run only when files in js
were changed with https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths
That said, if it takes less than 10 minutes, this is probably good enough...
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 don't have time to dive into the nitty-gritty details (e.g. tc39TestCtx.runTC39Test()
and how exactly the TC39 test suite is structured), but overall I quite like how you've structured the tests on the k6 side ❤️
@mstoykov, what do you think about exporting the ctx.errors
to another JSON file, and saving it as a build artifact in github actions, not just printing it to stdout
? That way it'd be easier to diff the changes when there are issues, and it shouldn't be too difficult to do.
.github/workflows/all.yml
Outdated
cd TestTC39/test262 | ||
git init | ||
git remote add origin https://github.com/tc39/test262.git | ||
git fetch origin --depth=1 72154b17fc99a26e79b2586960f059360d4ce43d |
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.
What is so special about this commit? And if you don't want to use master
because of potential future flakyness, can we have this commit ID as an environment variable, so it'd be a bit more visible and easier to update.
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.
This was the latest commit at the time I started :D
.github/workflows/all.yml
Outdated
@@ -83,6 +83,28 @@ jobs: | |||
fi | |||
go test "${args[@]}" -timeout 800s ./... | |||
|
|||
tc39: | |||
runs-on: ubuntu-latest | |||
steps: |
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.
We can move this to its own job, and have it run only when files in js
were changed with https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths
That said, if it takes less than 10 minutes, this is probably good enough...
} | ||
|
||
func TestTC39(t *testing.T) { | ||
if testing.Short() { |
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 had no idea this existed... And I'm not sure I even like it, given the existence of build flags. but oh well... 🤷♂️ On the other hand, I ❤️ the skip message below, and how we can optionally include the tc39 tests in our normal golang tests, or not!
Co-authored-by: na-- <[email protected]>
My current way of doing it is to I also do intend on coming back to enable/disable more tests and hopefully reorganize it so we can have proper concurrent execution ... and probably some memory usage reduction, so this will just be ... one more thing to fix ... next year :P |
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.
Fantastic work @mstoykov!!! 👏
I saw some commented out code in places, but there's probably a good reason you left it there, so it's fine.
I would echo Ned's suggestion to only run this if files in js
change, or even on master
commits and version tags only. We don't really need it for every PR, even if it takes less than 10 minutes.
The workflows change seems to work #1764 |
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 squash/rebase.
https://github.com/tc39/test262/blob/main/INTERPRETING.md Should probably be used as reference ... about what the test metadata (and not only) means