-
Notifications
You must be signed in to change notification settings - Fork 182
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
Updates related_integrations field API docs #5183
Updates related_integrations field API docs #5183
Conversation
A documentation preview will be available soon. Request a new doc build by commenting
If your PR continues to fail for an unknown reason, the doc build pipeline may be broken. Elastic employees can check the pipeline status here. |
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.
Left a few comments that apply to all the identical blocks as well but from a rules management definition pov, this looks good to me
|related_integrations |Object[] a| Fleet integrations the rule depends on. The object has three fields: | ||
|
||
* `package` (String, required): Integration package's name EPR uses | ||
* `integration` (String, optional): Integration's name. It's optional for packages with the only one integration whose name matches package name but required for packages with multiple integrations. |
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.
We might want to sort these by required and optional, although this is a weird field where in some cases it's optional and in others it's not
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.
@dplumlee Yeah, if this was strictly optional all the time, I'd say re-order the list, but since it's a little of both it's good ordered as it is.
This pull request is now in conflicts. Could you fix it @maximpn? 🙏
|
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.
Thanks @maximpn for creating these updates! Added a few suggestions and comments. I'm not sure what's causing the conflicts in the PR but will look at that next.
@@ -380,6 +380,12 @@ Required when `actions` are used to send notifications. | |||
|
|||
* `field_names`: String[] , required | |||
|
|||
|related_integrations |Object[] a| Fleet integrations the rule depends on. The object has three fields: |
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.
|related_integrations |Object[] a| Fleet integrations the rule depends on. The object has three fields: | |
|related_integrations |Object[] a| {integrations-docs}[Elastic integrations] the rule depends on. The object has these fields: |
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 seems vscode doesn't properly parse integrations-docs
link and shows it as is. Is there a way to verify it locally?
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.
@maximpn you can build the Security docs locally if you also have elastic/docs cloned on your machine. Run the command line build alias docbldsec --open
to build the Security docs, and they'll open in a browser.
That can be a bit involved, so the PR preview from CI is another way to verify. I checked and the link resolves correctly.
@@ -380,6 +380,12 @@ Required when `actions` are used to send notifications. | |||
|
|||
* `field_names`: String[] , required | |||
|
|||
|related_integrations |Object[] a| Fleet integrations the rule depends on. The object has three fields: | |||
|
|||
* `package` (String, required): Integration package's name EPR uses |
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.
Some users might not know what EPR stands for, or maybe they're unfamiliar with Elastic Package Registry in general. I'm also wondering how they'd find out what a given package's name is; maybe we can add a link to help them find the integration/packages they're trying to add?
I tried looking for a list in elastic/package-registry but didn't find anything. Maybe elastic/integrations/tree/main/packages?
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 don't think we have package name documented somewhere. For example this page shows integrations list. Package's name as well as integration's name are in fact identifies and hidden from users. UI fetches integrations list from EPR (of course not directly but via Fleet) and uses that ids for API requests. To be 100% sure about id correctness users should use EPR. EPR allows to search for a package while the package contains integrations. After that package or integration ids can be saved since these a stable.
@joepeeples what do you think the best approach to describe it?
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.
@maximpn Simpler is probably better; we can link users to the EPR repo, which documents the API requests that can help them search for the right packages and integrations.
* `package` (String, required): Integration package's name EPR uses | |
* `package` (String, required): The integration package's name, as used by the https://github.com/elastic/package-registry[Elastic Package Registry]. |
|related_integrations |Object[] a| Fleet integrations the rule depends on. The object has three fields: | ||
|
||
* `package` (String, required): Integration package's name EPR uses | ||
* `integration` (String, optional): Integration's name. It's optional for packages with the only one integration whose name matches package name but required for packages with multiple integrations. |
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.
* `integration` (String, optional): Integration's name. It's optional for packages with the only one integration whose name matches package name but required for packages with multiple integrations. | |
* `integration` (String, optional): The integration's name. This field is optional for packages with only one integration whose name matches the package name, but it's required for packages with multiple integrations. |
@@ -278,6 +278,12 @@ rule's version number is incremented by 1. | |||
`PATCH` calls enabling and disabling the rule do not increment its version | |||
number. | |||
|
|||
|related_integrations |Object[] a| Fleet integrations the rule depends on. The object has three fields: |
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.
|related_integrations |Object[] a| Fleet integrations the rule depends on. The object has three fields: | |
|related_integrations |Object[] a| {integrations-docs}[Elastic integrations] the rule depends on. The object has these fields: |
|related_integrations |Object[] a| Fleet integrations the rule depends on. The object has three fields: | ||
|
||
* `package` (String, required): Integration package's name EPR uses | ||
* `integration` (String, optional): Integration's name. It's optional for packages with the only one integration whose name matches package name but required for packages with multiple integrations. |
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.
* `integration` (String, optional): Integration's name. It's optional for packages with the only one integration whose name matches package name but required for packages with multiple integrations. | |
* `integration` (String, optional): The integration's name. This field is optional for packages with only one integration whose name matches the package name, but it's required for packages with multiple integrations. |
This pull request is now in conflicts. Could you fix it @maximpn? 🙏
|
acff659
to
e8dbbbb
Compare
Hi @joepeeples, I've updated the PR according to your comments. The last this left is to describe how to get a package name and a link to EPR documentation. Check my comment above. |
I've addressed your last comments. Could you review the recent changes? |
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.
Everything looks good, and now that we have an 8.15 branch we can merge and backport to that.
* allow editing related integrations * improve readability * add an EPR link --------- Co-authored-by: Joe Peeples <[email protected]> (cherry picked from commit c8aa530)
* allow editing related integrations * improve readability * add an EPR link --------- Co-authored-by: Joe Peeples <[email protected]> (cherry picked from commit c8aa530) Co-authored-by: Maxim Palenov <[email protected]>
Relates to: elastic/kibana#173595
Epic: https://github.com/elastic/security-team/issues/1974
Summary
API updates for elastic/kibana#173595.
Updates related API docs for related_integration field changes made in elastic/kibana#178295.