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.
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.
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
| name: apache | ||
| title: Apache | ||
| version: 0.1.4 | ||
| version: 0.2.7 |
There was a problem hiding this comment.
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.
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.
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
mtojek
left a comment
There was a problem hiding this comment.
@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. |
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! |
mtojek
left a comment
There was a problem hiding this comment.
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" |
| wipeDataStreamHandler func() error | ||
| } | ||
|
|
||
| type stackSettings struct { |
There was a problem hiding this comment.
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.
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.
| 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.
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.
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-streamglobal test flag to pipeline and system testsResolves #115.