Closed efd6 closed 1 year ago
Pinging @elastic/security-external-integrations (Team:Security-External Integrations)
@efd6,
Want me to start knocking some of these out? I won't have permissions to check boxes above, but I could refer to this issue for whichever PR's I create.
@MakoWish You are welcome to pick up any that are important to you.
Submit PR's for pretty much all that we use. Will see if I can get more time later to knock out a few more just to assist.
Didn't see modsecurity
in your m*
PR, so just knocked that one out. That should wrap this up, yeah?
Many thanks to @MakoWish.
@MakoWish : Thanks for your contributions here.
@efd6: As I discussed with you, this change will basically help us in using error.message to store errors other than pipeline errors as well, but it requires a change in Elastic Package as well since EP uses it for pipeline errors. Could you please share the ticket where the EP task is being tracked?
That will help us in pursuing the change done by @MakoWish to non-sei integrations.
cc: @andrewkroh
There is no ticket for this in EP. @jsoriano Do you have any information to add here?
Do you mean that elastic-package pipeline tests currently fail if they find an error.message
? Probably we can make it to fail only when error.kind
is pipeline_error
if we are going to use this field in all packages to indicate an actual pipeline error.
If the on_failure
part should be included in all packages, I wonder if it should be filled by elastic-package
on build time, or by Fleet on install time.
Please open an issue with details about this use case.
I have filed https://github.com/elastic/elastic-package/issues/1392.
I have filed elastic/elastic-package#1392.
Thanks!
SEI package style now requires that the global
on_failure
setserror.kind
to "pipeline_error". New package generally have this behaviour, but existing packages need to be brought up to date.Current packages (identified by CODEOWNERS) that do not do this are (package, data stream name and file):