-
Notifications
You must be signed in to change notification settings - Fork 150
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
fix: rewrite sidecar e2e script #618
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.
Cool! Offhand this looks like a definite step up from the python approach (and I for one like that the python dependency goes away :D)
Does the README need any tweaks now that python is no longer a dependency and such?
@jsdw Yea exactly. I need to update all the docs, and the scripts |
@jsdw I changed it up quite a bit if you want to take a second check. There were still some node processes that would not be handled correctly on random tests, so I ended up spawning them in their own groups and using pid ranges to kill all child processes and any possible descendants. All issues are completely handled now :) |
scripts/.eslintrc.js
Outdated
@@ -0,0 +1 @@ | |||
module.exports = require('@substrate/dev/config/eslint'); |
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.
Is eslint smart enough to look in the directory above?
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! 100% is. TIL :)
removed all the eslint configs from the scripts folder.
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.
except the eslintignore
// Kill all processes spawned and tracked by this file. | ||
const killAll = () => { | ||
console.log('Killing all processes...'); | ||
for (const key of Object.keys(procs)) { |
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 fully understand the considerations here, but is there any benefit in have procs
as a param to this function? And generally explicitly passing procs
around. Otherwise it is a global-ish object for this module, which is fine but I think might make refactoring in the future harder
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.
is there any benefit in have procs as a param to this function
I dont think in this situation there is much benefit. Preferably the script is completely stand alone, and doesn't interact with anything else which would stop any collisions or issues happening with procs
.
process.kill(-procs[key].pid, 'SIGTERM'); | ||
process.kill(-procs[key].pid, 'SIGKILL'); | ||
} catch (e) { | ||
/** |
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.
could console.error the message, but up to you
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.
Yea i thought about it too, but it will throw an error every time when using -procs[key].pid
here because there will be some 'pid' that sidecar already closed implicitly but is still within the group. The error is harmless, but the major thing is just making sure all process's close.
Co-authored-by: Zeke Mostov <32168567+emostov@users.noreply.github.com>
…rate-api-sidecar into tarik-update-e2e-script
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.
LGTM, scripts ran on the first try, looks like a good upgrade
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.
Looks great! I tried it and, for the first time ever, all tests passed without a hitch. I'll consider that a win :D
|
||
Note that the e2e tests will connect to running nodes in order to test sidecar against real data, and they may fail owing to those connections taking too long to establish. If you run into any failures, try running tests just for the chain that failed with something like `yarn test:init-e2e-tests:polkadot`. | ||
Note: that the e2e tests will connect to running nodes in order to test sidecar against real data, and they may fail owing to those connections taking too long to establish. If you run into any failures, try running tests just for the chain that failed with something like `yarn test:init-e2e-tests:polkadot`. |
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.
Nit: Maybe we don't need to repeat the per-chain bit now it's added above (but no harm in it really!)
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.
It might be worth keeping for now, but yea I am happy to remove it if it seems like extra bloat.
/** | ||
* Signal interrupt | ||
*/ | ||
process.on('SIGINT', function () { |
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 wonder whether it's worth covering a few more bases and also cleaning up when SIGKILL, SIGTERM (eg when kill command used) and SIGHUP (eg when terminal window closed) are sent?
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.
Yea I agree, I just added SIGHUP.
cleaning up when SIGKILL, SIGTERM (eg when kill command used)
Curious what you mean by that?
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, I just meant that SIGTERM is the default signal sent when kill
is used. Actually, I don't think you can catch SIGKILL looking at the kill
man page so that's not useful anyway!
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 thnk that catching the result of ctrl+c is most important though and you've done that, and now you've added the "terminal" closed signal that seems good to me!)
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.
Ahh okay cool i see what you are referencing at :)
closes: #611
Rewritten e2e tests script in typescript.