-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
[Tests]: add weekly scheduled smoke tests #2963
Conversation
CI's pretest steps are failing due to eslint version conflicts between dependencies.
The reason for
Merging #2825 should fix this. Or even |
Second and last conflict: version util test was checking actual installed dependencies. Now that |
package.json
Outdated
@@ -45,13 +45,14 @@ | |||
"@types/eslint": "^7.2.8", | |||
"@types/estree": "^0.0.47", | |||
"@types/node": "^14.14.37", | |||
"@typescript-eslint/parser": "^2.34.0", | |||
"@typescript-eslint/parser": "^3.10.1", |
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 seems like it would affect our ability to test on v2 of the parser. any thoughts/concerns?
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've been looking at this changelog of 2.34.0
-> 3.0.0
and don't think there's anything special in v2 that is being missing after upgrading to v3. Most important thing is the node v8 support being dropped out but I think that's it. But I must say I'm not expert when it comes to AST parsers. 🙃
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.
That means we wouldn't be able to use it on node 4 and 6 tests :-/
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.
That's definitely a drawback. Not sure how to resolve this. 😕
A bit off-topic but just to clarify - how was the v2.34.0
be able to run on node 4? It requires node v8 + eslint v5. ESLint v5 requires node 6. Am I reading these requirements correctly?
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.
actually you're right; the tests are set up to skip the TS tests on node < 5 (or maybe <= 5).
(this project supports down to eslint 3, which requires node 4)
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.
Alright so previously with v2.34.0
the TS tests have been run for eslint@^5
+ node@^8
.
Now the v3
supports eslint@^5
and node@^10
. The only thing that is lost is being able to test the typescript parser against node v8. ESLint version is still the same. That doesn't sound too bad, 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.
I think we can fix this by depending on ^2.34.0 || ^3.10.1
, and in the CI config, manually installing v2 when it's node < 10.
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.
Now using "@typescript-eslint/parser": "^2.34.0 || ^3.10.1"
and CI seems to be passing. Does it still require changes to CI workflow configurations?
Should the version be forced here?
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, I think that's precisely the solution that's needed :-)
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.
CI will now resolve version based on matrix.node
: "@typescript-eslint/parser@${{ matrix.node-version >= 10 && '3' || '2' }}"
.
The "ternary" syntax here is a bit weird but it works.
Logs from jobs:
latest majors (10, 7)
:* AFTER_INSTALL: npm install --no-save "eslint@7" "@typescript-eslint/parser@3"
latest majors (9, 6)
:* AFTER_INSTALL: npm install --no-save "eslint@6" "@typescript-eslint/parser@2"
hm, my other comment got lost. can the "list of repos" be fetched remotely? i don't really want to have to maintain a manual list of other people's repos if i can avoid it. (it's great to be able to override it locally if needed, ofc) |
That's something other developers have been asking too. These repositories have been fetched with a script for libraries.io but their service timeouts often and is extremely unstable, librariesio/libraries.io#2647. Maybe I should finally build some kind of centralized solution for this. Plugin projects could fetch these repositories from a hosted gist.github but that means they would need // eslint-remote-tester.config.js
const repositories = require('eslint-remote-tester-repositories');
module.exports = {
repositories: repositories.filter(repository => repository !== 'org/some-repository-which-we-dont-want'),
...
} I would like to avoid providing these from |
In the github action, it could be fetched with |
4632cea
to
547a1ff
Compare
Codecov Report
@@ Coverage Diff @@
## master #2963 +/- ##
=======================================
Coverage 97.38% 97.38%
=======================================
Files 111 111
Lines 7426 7426
Branches 2713 2713
=======================================
Hits 7232 7232
Misses 194 194 Continue to review full report at Codecov.
|
547a1ff
to
409c10c
Compare
Now using repositories from Also a notable change - removed passing |
.github/workflows/smoke-test.yml
Outdated
- run: | | ||
npm install | ||
npm link | ||
npm link eslint-plugin-react |
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 a bit confused why this is needed - npm link
alone ensures that the binary is globally available
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.
ESLint is unable load the plugin without this. As far as I understand, the npm link <package>
creates the actual symlink under projects node_modules
. Does this mean ESLint is unable to use globally available packages?
Here is example run without this line. https://github.com/AriPerkkio/eslint-plugin-react/runs/2477044926?check_suite_focus=true
Error: Configuration validation errors:
- eslintrc: Failed to load plugin 'react' declared in 'CLIOptions': Cannot find module 'eslint-plugin-react'
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.
ahhh yes, because eslint require
s it.
in that case, an alternative to "link to global, then link back down" is if we add to devDeps "eslint-plugin-react": "link:./"
, perhaps?
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.
"link:./"
seems to fail but "file:./"
works. No need to run link steps in workflow now. https://docs.npmjs.com/cli/v7/configuring-npm/package-json#local-paths
"eslint-plugin-react": "file:./",
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.
Oh actually I'll need to revert this change. Some older node versions seem to fail. Some fail in unit-test step, some fail in installation step.
https://github.com/yannickcr/eslint-plugin-react/actions/runs/803786800
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.
seems it behaves differently in npm 6 vs 7 :-/
package.json
Outdated
@@ -45,13 +45,14 @@ | |||
"@types/eslint": "^7.2.8", | |||
"@types/estree": "^0.0.47", | |||
"@types/node": "^14.14.37", | |||
"@typescript-eslint/parser": "^2.34.0", | |||
"@typescript-eslint/parser": "^3.10.1", |
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.
That means we wouldn't be able to use it on node 4 and 6 tests :-/
b82263e
to
338fc3b
Compare
Now using |
dc6f262
to
238cf8a
Compare
2ef5e00
to
f380d1d
Compare
f380d1d
to
e68f5a1
Compare
FYI, while testing this setup with latest Test has been running for 35mins and found hundreds of crashes: |
- in CI, use the proper version for the node version
e68f5a1
to
330404f
Compare
330404f
to
0894132
Compare
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.
Awesome, thanks!
Context: AriPerkkio/eslint-remote-tester#29
What
Adds weekly scheduled smoke tests to be run on every Sunday at 00:00. Tests can also be trigger manually (
workflow_dispatch
). These tests will be looking for rule crashes.Previously these tests have been run in
eslint-remote-tester
's repository. So far bugs below have been found by automated CI runs:jsx-no-constructed-context-values: Cannot read property 'set' of undefined
jsx-no-constructed-context-values: Cannot read property 'set' of undefined #2894jsx-no-constructed-context-values: Cannot read property 'type' of null
jsx-no-constructed-context-values: Cannot read property 'type' of null #2895no-unknown-property: allowedTags.indexOf is not a function
no-unknown-property: allowedTags.indexOf is not a function #2879jsx-max-depth: Maximum call stack size exceeded
jsx-max-depth: Maximum call stack size exceeded #2880jsx-wrap-multilines: RangeError: Invalid count value
jsx-wrap-multilines: RangeError: Invalid count value #2875jsx-no-script-url: Cannot read property 'type' of null
jsx-no-script-url: Cannot read property 'type' of null #2871no-typos: Cannot read property 'toLowerCase' of undefined
no-typos:Cannot read property 'toLowerCase' of undefined
#2870jsx-max-depth: Cannot read property 'length' of undefined
jsx-max-depth: Cannot read property 'length' of undefined #2869Add new rule "react/no-referential-type-default-prop"
[New] addno-object-type-as-default-prop
rule #2848forbid-dom-props
forbid-dom-props: supportJSXNamespacedName
#2961 (comment)How
Plugin maintainer making sure all existing rules do not crash
Utilizes https://github.com/marketplace/actions/eslint-remote-tester-runner. Each test run will check as many repositories as it can in 5 hours 30 minutes (default value of
timeLimit
).There are 10K repositories in
test/smoke-test-repositories.json
. The first ~3300 are specifically picked for this plugin as they have/react/
in the repository name. These were collected from libraries.io.At first the rules will be
extends: ['plugin:react/all']
but it is absolutely OK to includerules: {}
with settings for specific rules if wanted.Available configuration options:
eslint-remote-tester-run-action
: https://github.com/marketplace/actions/eslint-remote-tester-runner#action-parameterseslint-remote-tester
: https://github.com/AriPerkkio/eslint-remote-tester#configuration-optionsWhen test fails the @github-actions bot will open new issue with title
Results of weekly scheduled smoke test
. It will reuse the existing issue if previous one hasn't yet been closed. It's recommended to close the issues once their findings are fixed.🎉