Add include package to x-pack Metricbeat #9509
Conversation
|
@kaiyan-sheng This might explain if you had trouble with testing. |
The include package was not loaded so far which means modules were not included in the binary. Also this adds a main_test.go file which is used to build the test binary for the system tests.
ruflin
force-pushed
the
fix-xpack-binary
branch
from
b27ed9a
to
4276952
Compare
| @@ -0,0 +1,27 @@ | |||
| // Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one | |||
There was a problem hiding this comment.
@andrewkroh To build this binary should we add the logic to the Makefile or try to do it also in mage? Do we have that already somewhere else?
There was a problem hiding this comment.
@andrewkroh I just realised in 6.x filebeat x-pack I can run make filebeat.test but not in 7.0. I wonder if that is a missing PR in master or was removed on purpose?
There was a problem hiding this comment.
It was removed on purpose. The Makefiles in x-pack// are really minimal with just enough targets to make the existing CI systems continue to work. When you execute any of the targets that require the binary it will be produced (like mage unitTest, mage integTest, mage pythonUnitTest, or mage pythonIntegTest).
beats/x-pack/metricbeat/magefile.go
Line 155 in 6a4ce43
There was a problem hiding this comment.
What do you think about having a mage target for just building the test binary? I use this pretty often for manual test runs if I only want to run a subset of system tests.
There was a problem hiding this comment.
I won't add another command to the extensive list of commands we already have / need to use before every push to repo. Instead, I'll integrate this action (say build) within each command which interacts directly with the Go code (almost all commands now I guess) as the first step in a chain of actions, for example before setting up compose or checking fields: you don't compile so I fail in 20s and my CI slot is free again. Go compile time is pretty fast and this way we reduce cognitive load to everybody.
There was a problem hiding this comment.
Not sure I can follow. I'm not worried about the failing of the building the Beats binary but how I run for example the system tests only for the Elasticsearch module. To do this, I need to test binary.
There was a problem hiding this comment.
Yes, system tests should be run with mage too, so mage should check compile correctness before running system tests but not as a separate command. I propose that compile correctness is integrated within the system test command (and unit test, integration test, etc.) so it's checked always.
There was a problem hiding this comment.
I still don't understand how I will run a single test locally if we don't have the target without me manually coming up with the details for building it each time? My goal here is not to figure out if the binary compiles or not as part of CI.
There was a problem hiding this comment.
So yeah, my goal is that it's done within the CI :)
There was a problem hiding this comment.
Let's assume I build module foo localy: How do I test only this module locally? And I do not want to test the binary but if the module works. Pushing always to CI to see if it works is not an option as I want to be able to develop offline and that would be way too slow for quick development feedback.
|
Pinging @elastic/infrastructure |
|
jenkins, test this |
|
jenkins, test this |
The include package was not loaded so far which means modules were not included in the binary. Also this adds a main_test.go file which is used to build the test binary for the system tests.