-
Notifications
You must be signed in to change notification settings - Fork 11
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
Introduce performance testing when available #11
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.
💚
one note thought: feels that we're half the way in terms of the performance setup.
what I mean is the scripts to run are hard-coded but not baseline is provided here
(e.g. no docker-performance-run.sh
on performance-run.sh
exists here).
on the other side - having too many scripts at the root will get confusing: "are those run, not?"
thinking having performance
sub-folder (potentially later integration
) with the scripts that are optionaly activated might be a compromise, wdyt?
My main motivation for adding this is that the performance tests are also
run on top of a version list, like the normal tests.
And unfortunately Travis doesn’t allow us to just reuse the environment
matrix for secondary/terciary stages.
So because of this I’ve added this scaffolding that plugins can either
reuse or redefine when needed.
…On Thu, 26 Mar 2020 at 11:57, Karol Bucek ***@***.***> wrote:
***@***.**** commented on this pull request.
💚
one note thought: feels that we're half the way in terms of the
performance setup.
what I mean is the scripts to run are hard-coded but not baseline is
provided here
(e.g. no docker-performance-run.sh on performance-run.sh exists here).
on the other side - having too many scripts at the root will get
confusing: "are those run, not?"
thinking having performance sub-folder (potentially later integration)
with the scripts that are optionaly activated might be a compromise, wdyt?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#11 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAHYQNWSGJKHO3HAXAM5HLRJM7LZANCNFSM4LUD4MHQ>
.
|
@kares I have refactored the performance snippet to call scripts located in the [edit] the resulting impact in the grok filter PR can be seen here: https://github.com/logstash-plugins/logstash-filter-grok/pull/159/files#diff-a963fe113db620873f1bd0c3e93b2348 |
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.
💓 🙇♂️ 🍹
leverage logstash-plugins/.ci#11 to run performance tests
* 1.x: Feat: upgrade linux dist image used for tests (#18) docker: fallback to arch-specific docker images where noarch unavailable docker: propagate DISTRIBUTION_SUFFIX to declaration of image base Keep testing the upcoming 7.x minor release Fix: locate `java` for 8.0 (SNAPSHOT) images update stack from 7.9.0 to 7.9.1 Update 7.x snapshot version Run performance testing when available (#11) allow the use of a extended docker-compose override file (#9) account for plugins having separate version files ensure rake vendor runs during setup bump to 1.x branch
No description provided.