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
Enable package compatibility checks with older Elastic stacks #740
Conversation
Blocked by: elastic/beats#24163 |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪 |
I found a weird behavior when used
I will try with releases, e.g. |
Ok, without SNAPSHOT tags, the elastic-package properly considers the version as valid/compatible. It fails because of #745 (need to merge this one first). |
I think I have to improve the elastic-package, as it supports only released version:
|
@ycombinator it's not ready for merge yet ( EDIT: I think I will fix the condition in a follow up PR. This one already polishes a couple packages in terms of compatibility. |
try { | ||
dir("${BASE_DIR}/packages/${integrationName}") { | ||
sh(label: "Boot up the Elastic stack (${stackVersion})", script: "../../build/elastic-package stack up -d -v --version ${stackVersion}") | ||
sh(label: "Install integration: ${integrationName}", script: ''' |
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.
So it seems we are calling a package as compatible if we are able to install it. Is this sufficient or do we also want to run tests for the package against the previous stack versions?
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.
No, I prefer to stick to installation as testing will elongate test execution much (+20minutes).
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.
Understood. Does installing a package result in any testing? In other words, what are the reasons this step would fail in CI?
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.
e.g. installation can check if all Kibana objects can be installed (correct migrationVersion field).
@@ -11,7 +11,7 @@ release: experimental | |||
license: basic | |||
type: integration | |||
conditions: | |||
kibana.version: '^7.9.0' | |||
kibana.version: '^7.11.0' |
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 didn't understand why we need these kibana.version
bumps here and in other packages in this PR?
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.
It's because of the fact that these packages are not compatible with older Kibana stacks.
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 see. Is there a reason these changes are part of this PR? In other words, do we need these changes anyway even without this PR? Did the compatibility checks introduced in this PR catch that these packages needed kibana version bumps?
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.
Did the compatibility checks introduced in this PR catch that these packages needed kibana version bumps?
Yes, exactly this. Otherwise the CI for this PR will be red.
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. This is a nice addition!
…c#740) * Start stack two more times * Check package compatibility with older stacks * Correct versions * nit * Fix * Fix: ignore prerelease * Adjust versions * Update release numbers * Fix: shellinit * Fix * Fix * Fix * Fix compatibility with Kibana
What does this PR do?
This PR enables package compatibility checks with older Elastic stacks. A package will be installed (not tested) in Kibana.
Checklist
- [ ] I have reviewed [tips for building integrations](https://github.com/elastic/integrations/blob/master/docs/tips_for_building_integrations.md) and this pull request is aligned with them.- [ ] I have verified that all data streams collect metrics or logs.- [ ] I have added an entry to my package'schangelog.yml
file.How to test this PR locally
CI will verify it.
Related issues