-
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
More cmd/
refactoring to simplify test loading and support integration tests
#2412
Conversation
With the latest commit here, we can now write dead-simple and safe integration tests 🎉 See this for an example: Lines 24 to 37 in 441a8f0
So between this and the fact that we have xk6 integration tests in our CI, I think it's pretty safe to close #342 once this PR is merged 🎉 |
cmd/
to simplify and unify test loadingcmd/
to simplify test loading and support integration tests
And yeah, I consider these to be integration tests because this is what Lines 23 to 29 in 441a8f0
Lines 297 to 301 in 441a8f0
And this is what an integration test in Lines 27 to 30 in 441a8f0
The two are basically the same, only the integration test has a dedicated environment (so we can run it safely in parallel) and also complete control that environment 🎉 |
cmd/
to simplify test loading and support integration testscmd/
refactoring to simplify test loading and support integration tests
7574bd2
to
691be6b
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.
Thumbs up from me 👍 🎉 Kudos for those changes, I do believe they will make our lives easier indeed!
I do think it would be beneficial to find better names for some of the APIs introduced in this PR; see my comments smiley 🐱
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.
Besides my few comments on naming, looking good! The yak is shaved, and we're equipped to make ourselves a nice pull-over for the next winter. Kudos 🎉
This actually also fixes a minor bug where the CLI flag was available in `k6 run` and `k6 inspect`, but it wasn't available in `k6 cloud` and `k6 archive`.
runtimeOptions lib.RuntimeOptions | ||
metricsRegistry *metrics.Registry | ||
builtInMetrics *metrics.BuiltinMetrics | ||
initRunner lib.Runner // TODO: rename to something more appropriate |
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 runner
I mean it seems to be the only runner either way.
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.
Maybe, but I'd prefer to wait with the final refactor and rename before messing with the names more...
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 in general. I have some naming comments that can be addressed in a separate PR
hardStop := func(sig os.Signal) { | ||
logger.WithField("sig", sig).Error("Aborting k6 in response to signal, we won't wait for the test to end.") | ||
os.Exit(int(exitcodes.ExternalAbort)) | ||
}() |
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.
The names here are not ... good IMO.
I was really confused that gracefulStop
does something while hardStop
just logs and does not os.Exit
.
I would argue they are not great in the handleTestAbortSignals
either.
I would recommend adding on
in front the names in all places. This still isn't great, but I feel a lot better about onHardStop
not calling os.Exit
explicitly and only logging, while onGracefulStop
actually doing something.
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.
Or maybe just have os.Exit
in both hardStops 🤷 I kind of feel like this DRY-ing of the code isn't really worth it
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.
👍 for gracefulStop
and onHardStop
Regarding the DRY, keep in mind that this will be used at least 2 more times, in k6 coordinate
and k6 agent
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.
(for expediency, I will address this in the next PR)
if secondHandler != nil { | ||
secondHandler(sig) | ||
} |
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: is this nil check 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.
Yes, I think so, if os.Exit()
is here. And I kind of like it to be here, to softly force the user to acknowledge that a second Ctrl+C should always abort the execution almost immediately, not be something optional.
TestType null.String `json:"-"` | ||
|
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 do actually write this in the archive under type
https://github.com/grafana/k6/blob/master/js/bundle.go#L190
maybe one day we can make MakeArchive outside of a Runner 🤷
More yak shaving, but after this, some parts of
cmd/
are almost normal looking 😅 🎉 I particularly like how cleancmd/archive.go
became 🎉k6/cmd/archive.go
Lines 44 to 72 in 147e3d1
Closes #342