-
Notifications
You must be signed in to change notification settings - Fork 442
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
Add a note regarding kibana.version #4970
Add a note regarding kibana.version #4970
Conversation
Signed-off-by: Tetiana Kravchenko <[email protected]>
```yaml | ||
conditions: | ||
kibana.version: '^8.7.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.
Can you please add a few words to explain how it behaves if you add a condition on a version of kibana that's hasn't been released yet. That I think it's very important to track from our meeting
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 you mean smth like 4bb0c61#diff-7829d8dddd64275f212ffcac52de0d8f8de3f6973c89a385c66be7072d3f75d7R110 ?
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.
Add a note about future kibana releases
💔 Tests Failed
Expand to view the summary
Build stats
Test stats 🧪
Test errors
Expand to view the tests failures> Show only the first 10 test failures
|
🌐 Coverage report
|
4. If introduced package changes must be compatible with a specific stack or beats version, `kibana.version` condition should be adjusted accordingly in the package's `manifest.yml`: | ||
```yaml | ||
conditions: | ||
kibana.version: '^8.7.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.
This list refers to actions when the version of the package needs to be updated with a set of Pull Requests.
What about adding this information as a new subsection in the a generic guideline doc here ? https://github.com/elastic/integrations/blob/main/docs/generic_guidelines.md
WDYT ? @tetianakravchenko
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.
@mrodm generic_guidance seems to provide a more generic information, without manifest examples, would maybe https://github.com/elastic/integrations/blob/main/docs/tips_for_building_integrations.md#manifest-files-1 be the better place? WDYT?
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.
That doc looks good 👍
Signed-off-by: Tetiana Kravchenko <[email protected]>
conditions: | ||
kibana.version: '^8.7.0' | ||
``` | ||
> Note: The package version with such condition will be only available in Kibana version >=8.7.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.
yes... and personally I would slightly rephrase it something like
It's safe to release an integration that is only compatible with a future Kibana version (meaning a release that is not out yet). In that case the integration will be available in the package registry but nobody will be able to upgrade to the new version until that Kibana version has been released.
WDYT?
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.
done. 60202c2
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.
@gsantoro actually I am not sure if it correct looking on #4948 (review)
changed accordingly to the commend above - dd1e3dd
Signed-off-by: Tetiana Kravchenko <[email protected]>
…t be unsage Signed-off-by: Tetiana Kravchenko <[email protected]>
|
||
It's safe to release an integration package that is only compatible with a future Kibana version (meaning a release that is not out yet). In that case the integration will be available in the package registry, but nobody will be able to upgrade to the new version until that Kibana version has been released. | ||
> Note: Changing dashboards and visualizations using an unreleased version of Kibana might be unsafe since the Kibana Team might make changes to the Kibana code and potentially the data models. There is no guarantee that your changes won't be broken by the time new Kibana version is released. |
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.
this changes things. What should @constanca-m do then. hold on to release the integration?
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 changes on the beats repository were backported to version 8.6. I will wait until they are available (I'm guessing on 8.6.1), and then I will continue the integrations PR @gsantoro
@mrodm could you please have a look? tests are failing because of the packages tests, and also maybe it is possible to exclude the |
@tetianakravchenko those CI errors are unrelated, there is an issue about this #4950 Is this PR already ready to be merged ? As these are docs, I could force the merge it if it is everything ready. |
yes, it is ready |
Signed-off-by: Tetiana Kravchenko [email protected]
What does this PR do?
Add information about package compatibility with stack/beats version
Checklist
changelog.yml
file.Author's Checklist
How to test this PR locally
Related issues
Screenshots