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
[Uptime][Synthetics Integration] Add browser monitors configuration options #102928
[Uptime][Synthetics Integration] Add browser monitors configuration options #102928
Conversation
Pinging @elastic/uptime (Team:uptime) |
: undefined | ||
} | ||
isInvalid={!!validate[ConfigKeys.RESPONSE_HEADERS_CHECK]?.(fields)} | ||
error={[ |
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 do not remember why this was made an array. My gut tells me that this is not needed.
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 probably ok to change it then; it seems to accept ReactNode | ReactNode[]
, so we aren't losing anything by simplifying it to a string
.
} | ||
> | ||
<SourceField | ||
onChange={useCallback( |
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.
hmm inline memo, or call back hooks, i was tempted to do this other day , not sure if it has any implications, probably none.
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.
As long as it's not conditional I think it's fine. My preference is to keep all hook usage isolated to its own block in the root of the function though, just because I find it to be more readable.
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.
Just some basic comments, code is looking pretty good.
} | ||
> | ||
<SourceField | ||
onChange={useCallback( |
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.
As long as it's not conditional I think it's fine. My preference is to keep all hook usage isolated to its own block in the root of the function though, just because I find it to be more readable.
error={ | ||
<FormattedMessage | ||
id="xpack.uptime.createPackagePolicy.stepConfigure.monitorIntegrationSettingsSection.timeout.error" | ||
defaultMessage="Timeout must be 0 or greater and less than schedule interval" |
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 copy is confusing. Could we break this up and conditionally render one or the other?
// pseudocode
error={
timeout < 0
? <FormattedMessage id="xpack.uptime.createPackagePolicy.stepConfigure.monitorIntegrationSettingsSection.timeout.lessThanZeroError"
defaultMessage="Timeout may not be less than 0"
/>
: <FormattedMessage id="greaterThanTimeout"
defaultMessage=""Timeout cannot be less than schedule interval"
/>
{ | ||
id: 'syntheticsBrowserZipURLConfig', | ||
name: ( | ||
<FormattedMessage |
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.
Seems we are repeating this definition in the content
section below, extract to a common definition above?
@elasticmachine merge upstream |
…ynthetics-integration-browser-monitors
@elasticmachine merge upstream |
@elasticmachine merge upstream |
…ynthetics-integration-browser-monitors
… the integration package
f158d1c
to
4919aba
Compare
@elasticmachine merge upstream |
|
||
return ( | ||
!timeout || | ||
parseFloat(timeout as ICustomFields[ConfigKeys.TIMEOUT]) < 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.
Could extract this cast to a var before the return statement, to avoid the repetition.
parseInt(fields[ConfigKeys.TIMEOUT], 10) < 0 ? ( | ||
<FormattedMessage | ||
id="xpack.uptime.createPackagePolicy.stepConfigure.monitorIntegrationSettingsSection.timeout.lessThanZeroError" | ||
defaultMessage="Timeout must be less than 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.
Seems like this is a typo.
defaultMessage="Timeout must be less than 0" | |
defaultMessage="Timeout must be greater than 0" |
) : ( | ||
<FormattedMessage | ||
id="xpack.uptime.createPackagePolicy.stepConfigure.monitorIntegrationSettingsSection.timeout.moreThanIntervalError" | ||
defaultMessage="Timeout cannot be more than the monitor interval" |
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 think "greater than" might be a little nicer. Just my opinion though.
defaultMessage="Timeout cannot be more than the monitor interval" | |
defaultMessage="Timeout cannot be greater than the monitor interval" |
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 updated this to say Timeout must be less than the monitor interval
. I thought that was more consistent. Thoughts?
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.
Seems fine to me.
@@ -458,7 +519,7 @@ describe('<SyntheticsPolicyEditExtension />', () => { | |||
const urlError = getByText('URL is required'); | |||
const monitorIntervalError = getByText('Monitor interval is required'); | |||
const maxRedirectsError = getByText('Max redirects must be 0 or greater'); | |||
const timeoutError = getByText('Timeout must be 0 or greater and less than schedule interval'); | |||
const timeoutError = getByText('Timeout must be less than 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.
Think this is a typo.
const timeoutError = getByText('Timeout must be less than 0'); | |
const timeoutError = getByText('Timeout must be greater than 0'); |
await waitFor(() => { | ||
const hostError = getByText('Zip URL is required'); | ||
const monitorIntervalError = getByText('Monitor interval is required'); | ||
const timeoutError = getByText('Timeout must be less than 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.
const timeoutError = getByText('Timeout must be less than 0'); | |
const timeoutError = getByText('Timeout must be greater than 0'); |
helpText={ | ||
<FormattedMessage | ||
id="xpack.uptime.createPackagePolicy.stepConfigure.monitorIntegrationSettingsSection.tags.helpText" | ||
defaultMessage="A list of tags that will be sent with the monitor event. Press enter to add a new tab. Displayed in Uptime and enables searching by tag." |
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.
Again I'm not a copy expert but I think this conveys the necessary information. cc @andrewvc
defaultMessage="A list of tags that will be sent with the monitor event. Press enter to add a new tab. Displayed in Uptime and enables searching by tag." | |
defaultMessage="A list of tags to apply to the monitor event. Press enter to add a new tab. Enables searching by tag." |
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.
Pulled from documentation https://www.elastic.co/guide/en/beats/heartbeat/current/monitor-options.html
x-pack/plugins/uptime/public/components/fleet_package/browser/source_field.tsx
Outdated
Show resolved
Hide resolved
), | ||
content: ( | ||
<EuiFormRow | ||
isInvalid={!!config.inlineScript} |
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.
You didn't implement a custom AST analyzer? 😉
[ConfigKeys.TIMEOUT]: (fields) => secondsToCronFormatter(fields[ConfigKeys.TIMEOUT]), | ||
}; | ||
|
||
export const arrayToYamlFormatter = (value: string[] = []) => |
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 code doesn't seem like it's directly tested.
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's true. It is covered by functional tests that ultimately test the input of the form to the output of the yaml integration policy, but I'll add tests.
x-pack/plugins/uptime/public/components/fleet_package/custom_fields.test.tsx
Outdated
Show resolved
Hide resolved
…simple_fields.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co>
…source_field.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co>
…ields.test.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co>
…ple_fields.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co>
89c4e41
to
8fca58f
Compare
This is looking great, I've done another round of smoke testing and it appears to be working fantastically. You've addressed most of the necessary code as well. I have noticed that the false error message I noticed in my earlier review is still happening. Haven't noticed any other blocking issues though. |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
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!
…ptions (elastic#102928) * update types * add browser context * update validation * add browser fields to custom fields * add browser simple fields and source field * add browser context to create and edit wrappers * update content * add formatters for formatting javascript values to integration policy yaml * fix policy name bug * adjust tests * adjust types * add normalizers for converting yaml to javascript * update default values * add params field to browser monitors * adjust types, formatters and normalizers to account for browser advanced fields * add browser advanced fields context and components * adjust http and tcp providers * adjust use_update_policy and wrappers * update types * update content * adjust timeout content * adjust zip url content * adjust content * remove unused content * hide monitor options that do not have corresponding data streams from the integration package * Update x-pack/plugins/uptime/public/components/fleet_package/browser/simple_fields.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co> * Update x-pack/plugins/uptime/public/components/fleet_package/browser/source_field.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co> * Update x-pack/plugins/uptime/public/components/fleet_package/custom_fields.test.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co> * Update x-pack/plugins/uptime/public/components/fleet_package/http/simple_fields.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co> * adjust content * adjust validation * adjust tests * adjust normalizers and formatters and add tests * resolves validation error with inline scripts Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Justin Kambic <justin.kambic@elastic.co>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…ptions (#102928) (#108911) * update types * add browser context * update validation * add browser fields to custom fields * add browser simple fields and source field * add browser context to create and edit wrappers * update content * add formatters for formatting javascript values to integration policy yaml * fix policy name bug * adjust tests * adjust types * add normalizers for converting yaml to javascript * update default values * add params field to browser monitors * adjust types, formatters and normalizers to account for browser advanced fields * add browser advanced fields context and components * adjust http and tcp providers * adjust use_update_policy and wrappers * update types * update content * adjust timeout content * adjust zip url content * adjust content * remove unused content * hide monitor options that do not have corresponding data streams from the integration package * Update x-pack/plugins/uptime/public/components/fleet_package/browser/simple_fields.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co> * Update x-pack/plugins/uptime/public/components/fleet_package/browser/source_field.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co> * Update x-pack/plugins/uptime/public/components/fleet_package/custom_fields.test.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co> * Update x-pack/plugins/uptime/public/components/fleet_package/http/simple_fields.tsx Co-authored-by: Justin Kambic <justin.kambic@elastic.co> * adjust content * adjust validation * adjust tests * adjust normalizers and formatters and add tests * resolves validation error with inline scripts Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Justin Kambic <justin.kambic@elastic.co> Co-authored-by: Dominique Clarke <doclarke71@gmail.com> Co-authored-by: Justin Kambic <justin.kambic@elastic.co>
Summary
Relates to elastic/uptime#276
This PR adds the corresponding UI to support browser monitor configuration within the Synthetics integration package.
Testing
This feature involves coordinated changes from kibana, integrations, and beats. In order to test e2e, it is necessary to pull down each PR separately. However, there are a few things you can test without every piece.
FULL DEV ENVIRONMENT SETUP INSTRUCTIONS: https://docs.google.com/document/d/1mS_94T0zRBtdJZVWLWc_B7iswTfkrGJXn9XMyt9JZjY/edit
Checklist
Uptime PR Checklist
The following considerations have been addressed