-
Notifications
You must be signed in to change notification settings - Fork 116
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
Asset loading test runner #168
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
|
06e1d5b
to
4a0b952
Compare
41fd971
to
47ec7e2
Compare
@mtojek This PR is ready for review, when you get a chance. Before this PR we had 2 test runners, both of which operated at the data stream level and needed test configuration. This PR introduces a test runner that operates at the package level and also doesn't need test configuration. As a result, the code for the test runner framework is now a bit of a mess IMO. I would like to clean this up but in a follow up PR. WDYT? |
|
||
// RemovePackage removes the given package from Fleet. | ||
func (c *Client) RemovePackage(pkg packages.PackageManifest) ([]packages.Asset, error) { | ||
return managePackage(pkg, "remove", c.delete) |
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 have a gut feeling that clients in ingestmanager
are too much complex. Not sure if we need as many layers to process a single request. Maybe not depending on common abstraction would be simpler?
Please take a look at https://github.com/elastic/elastic-package/blob/master/internal/kibana/saved_objects.go . In this case I need to implement paging and the exact code responsible for calls to Kibana is wrapped up in ca. 20 LOCs: https://github.com/elastic/elastic-package/blob/master/internal/kibana/saved_objects.go#L95-L118
I'm happy to discuss it!
internal/packages/assets.go
Outdated
} | ||
assets = append(assets, a...) | ||
|
||
a, err = loadFileBasedAssets(kibanaAssetsFolderPath, AssetTypeKibanaMap) |
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.
Thinking loud: shouldn't elastic-package discover available types from the package directory? In case we add a new type the command will still operate (open-closed principle).
test/packages/apache/manifest.yml
Outdated
@@ -1,7 +1,7 @@ | |||
format_version: 1.0.0 | |||
name: apache | |||
title: Apache | |||
version: 0.1.4 | |||
version: 0.2.7 |
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 this change on purpose?
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 had to make it because the package registry image loaded up by the tests installs Apache version 0.2.6. So, in order for the asset test runner to be able to install the local apache package (i.e. the one being tested), I had to ensure that the local apache package's version was greater than the one in the registry. Otherwise the Install Package API would not allow the local package to be loaded up.
I admit that this is not a very maintainable change. Every time the package registry image is refreshed with a newer version of apache
, we will need to bump up the version here as well. Maybe we should just set it here to something like 999.999.999
?
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 see :) In this case you can set it to sth weird like 999. (at least the major). Nice catch!
scripts/test-check-packages.sh
Outdated
for d in test/packages/*/; do | ||
( | ||
cd $d | ||
elastic-package build -v |
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 you please double-check if the check
command doesn't include build
step?
TODO: consider implementing #175 (comment) as part of this PR. |
5a70284
to
3820375
Compare
3820375
to
380bcb0
Compare
380bcb0
to
f13bba7
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.
@ycombinator please let me know whether I can take another look at this PR.
Yeah, I'm still iterating on it. I'll re-request your review when it's ready for you to take a look. Thanks! |
23fb729
to
36a28f5
Compare
36a28f5
to
693a1f8
Compare
I see that CI is failing. I will look into this tomorrow. |
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 implementation looks good to me.
Let's move forward with this PR. Did you take a chance to run it against real integrations?
nit: just rebase the PR against master branch
0e527da
to
4ec725f
Compare
Seeing this error now:
Will look into it tomorrow. |
Hi @mtojek, I made a few small changes since your last review to make CI pass. Could you please take another look when you get a chance? Thanks! |
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.
Thank you for the heads up! I left some minor comments, but wouldn't like to block your PR from merging. These ones can be addressed in follow up PRs (up to you).
I'm thrilled to see this running in the Integrations. Nice job!
AssetTypeKibanaSavedSearch AssetType = "search" | ||
AssetTypeKibanaVisualization AssetType = "visualization" | ||
AssetTypeKibanaDashboard AssetType = "dashboard" | ||
AssetTypeKibanaMap AssetType = "map" |
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.
- Lens
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.
Addressed in 133e50e.
@@ -51,17 +51,6 @@ type runner struct { | |||
wipeDataStreamHandler func() error | |||
} | |||
|
|||
type stackSettings struct { |
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 the stackSettings
(old and new) structure used anywhere? It looks like a leftover after refactoring. All stack settings like host, login, password don't need to be exposed beyond ES/Kibana clients.
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.
Good catch. I've removed all stack settings code in cef5f22. So now the ES/Kibana clients directly call os.Getenv
in their constructors to get the stack settings.
@@ -223,5 +237,5 @@ func isDataStreamManifest(path string) (bool, error) { | |||
if err != nil { | |||
return false, errors.Wrapf(err, "reading package manifest failed (path: %s)", path) | |||
} | |||
return m.Title != "" && (m.Type == "logs" || m.Type == "metrics"), nil | |||
return m.Title != "" && (m.Type == dataStreamTypeLogs || m.Type == dataStreamTypeMetrics), nil |
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: Actually this function isn't perfect. If there is another dataset type, it will simply fail (OCP broken). I wonder if there is a different way to recognize the DataStream. If you find any, feel free to adjust the implementation.
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.
Yeah, it's not perfect but I think this check here might have some good side-effects. In the asset test runner we check if we are dealing with a logs
data stream and, if so, check that ingest pipeline assets have also been loaded. Similarly, whenever a new data stream type is added in the future we might need to have special handling for it somewhere in elastic-package
. So being strict here about which data stream types elastic-package
knows how to handle may be a good thing.
Case in point: I was checking the data stream manifest spec to see if we have defined the data stream type
field as an enum
and we have. However, while doing this I noticed that there is a data stream type we have not yet considered in elastic-package
: traces
. It was added for APM in elastic/package-spec#78. I'm guessing the APM team is not using elastic-package
yet so they are not running into any issues with this type not being supported. I've created #223 to track adding support for this type in elastic-package
.
e4feb39
to
cef5f22
Compare
@mtojek I've addressed all your feedback. Please re-review when you get a chance. If the PR looks good to you, please merge it on my behalf as I'll be away from work for the next week. Otherwise I will address any further feedback when I'm back. Thanks! |
This PR implements a new type of test runner:
asset
. This test runner tests whether a package's assets (ES index templates, Kibana dashboards, etc.) are loaded up as expected.Sample usage
TODO
--data-stream
global test flag to pipeline and system testsResolves #115.