-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
quick check of current URL to skip timepicker #146462
Conversation
The visualize app failure "FTR Configs #50 / visualize app - new charts library visualize area charts date histogram interval expanded accordion should update scaled label text after custom interval is set and time range is changed" is a case where the timepicker already had the time that was being set so it didn't set it. So it might be appropriate to change the test to pick a slightly different time (even just 1 second different) so that the custom interval reset as the test expects. I'll try that.
UPDATE: I resolved this by changing setAbsoluteTime to be a wrapper around the old functionality and renaming setAbsoluteTime to setAbsoluteTimeAlways. But I'm thinking a better name might be setAbsoluteTimeForce? |
Here's a bit of data from main branch where I added timestamps to the test output with a set of Lens tests running which keep setting the timepicker to the same time. They're all setting the same time in each test. Each call to setAbsoluteTime takes about 3 seconds. One lens test indirectly calls setAbsoluteTime 23 times! And all combined lens tests call it 82 times.
Compared to this PR (I added debug logging just to see the start and end of the URL check) which shows that it only takes less than 1s to check if the desired dates are in the URL;
|
* @param {String} fromTime MMM D, YYYY @ HH:mm:ss.SSS | ||
* @param {String} toTime MMM D, YYYY @ HH:mm:ss.SSS | ||
*/ | ||
public async setAbsoluteRangeAlways(fromTime: string, toTime: 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.
I'm not in love with the name setAbsoluteTimeAlways
and thought setAbsoluteTimeForce
might be better?
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.
Possible alternative
/**
* @param {String} fromTime MMM D, YYYY @ HH:mm:ss.SSS
* @param {String} toTime MMM D, YYYY @ HH:mm:ss.SSS
* @param {Boolean} force time picker force update, default is false
*/
public async setAbsoluteRange(fromTime: string, toTime: string, force = false) {
Maybe It won't be bad to call function few time like
await PageObjects.timePicker.setAbsoluteRange(fromTime, toTime, true);
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
const DEFAULT_DATE_FORMAT = 'MMM D, YYYY @ HH:mm:ss.SSS'; | ||
const startMoment = moment.utc(fromTime, DEFAULT_DATE_FORMAT).toISOString(); | ||
const endMoment = moment.utc(toTime, DEFAULT_DATE_FORMAT).toISOString(); | ||
if (currentUrl.includes(startMoment) && currentUrl.includes(endMoment)) { |
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.
Maybe I'm late to jump here, but just one thought. Maybe we can make a more strict times check?
currentUrl.includes(`time:(from:'${startMoment}',to:'${endMoment}')`)
I guess the format is consistent across the plugins, right?
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.
Before I even read the rest of this, I wonder if it's worth to strongly type the format.
Actually, I'm hoping that's been done somewhere in this repo already.
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 got @dmlemeshko 's suggestion to work. I had to decodeURI.
…mepickerChecksUrl
Pinging @elastic/kibana-qa (Team:QA) |
buildkite test this |
I took some time testing it locally and seems like it works perfect:
outputs
so time picker is set only first time, the actual url was |
*/ | ||
public async setAbsoluteRange(fromTime: string, toTime: string) { | ||
public async setAbsoluteRange(fromTime: string, toTime: string, force = false) { |
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.
Under what circumstances does it make sense to force?
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.
Off the top of my head, anytime flakiness is encountered (timepicker can be notorious sometimes).
This pr is a pr from a former elastic employee (our boss) and we did discuss at some length.
Further, there is some use of force flag within this pr.
@dmlemeshko may have more to weigh in on this.
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.
@andrewctate , it is a good question. For some reason Lee picked area chart, maybe he was doing some testing.
You might know more about this test, and if there is no good reason re-resetting the time picker with already the same range, I can push an update and remove 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.
@dmlemeshko I agree with Andrew, this test was not flaky. I might miss something here but I would propose to remove it!
buildkite test this |
💚 Build Succeeded
Metrics [docs]Unknown metric groupsESLint disabled in files
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
## Summary We have some tests which set the default time but then also call setAbsoluteTime in every test. This PR adds code in setAbsoluteTime to quickly check if the desired start and end (from and to) times are already set, and if so, just return. The end result should be less time spent on functional tests. It could also reduce occasional flakiness setting the time. Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co> (cherry picked from commit 1734b0e)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
# Backport This will backport the following commits from `main` to `8.6`: - [quick check of current URL to skip timepicker (#146462)](#146462) <!--- Backport version: 8.9.7 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Lee Drengenberg","email":"lee.drengenberg@elastic.co"},"sourceCommit":{"committedDate":"2022-12-04T20:50:50Z","message":"quick check of current URL to skip timepicker (#146462)\n\n## Summary\r\n\r\nWe have some tests which set the default time but then also call\r\nsetAbsoluteTime in every test. This PR adds code in setAbsoluteTime to\r\nquickly check if the desired start and end (from and to) times are\r\nalready set, and if so, just return. The end result should be less time\r\nspent on functional tests. It could also reduce occasional flakiness\r\nsetting the time.\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>","sha":"1734b0e5db897453bcd532f2896234aa15db8139","branchLabelMapping":{"^v8.7.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:QA","test_ui_functional","test_xpack_functional","release_note:skip","backport:prev-minor","v8.7.0"],"number":146462,"url":"https://github.com/elastic/kibana/pull/146462","mergeCommit":{"message":"quick check of current URL to skip timepicker (#146462)\n\n## Summary\r\n\r\nWe have some tests which set the default time but then also call\r\nsetAbsoluteTime in every test. This PR adds code in setAbsoluteTime to\r\nquickly check if the desired start and end (from and to) times are\r\nalready set, and if so, just return. The end result should be less time\r\nspent on functional tests. It could also reduce occasional flakiness\r\nsetting the time.\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>","sha":"1734b0e5db897453bcd532f2896234aa15db8139"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.7.0","labelRegex":"^v8.7.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/146462","number":146462,"mergeCommit":{"message":"quick check of current URL to skip timepicker (#146462)\n\n## Summary\r\n\r\nWe have some tests which set the default time but then also call\r\nsetAbsoluteTime in every test. This PR adds code in setAbsoluteTime to\r\nquickly check if the desired start and end (from and to) times are\r\nalready set, and if so, just return. The end result should be less time\r\nspent on functional tests. It could also reduce occasional flakiness\r\nsetting the time.\r\n\r\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>","sha":"1734b0e5db897453bcd532f2896234aa15db8139"}}]}] BACKPORT--> Co-authored-by: Lee Drengenberg <lee.drengenberg@elastic.co>
Summary
We have some tests which set the default time but then also call setAbsoluteTime in every test. This PR adds code in setAbsoluteTime to quickly check if the desired start and end (from and to) times are already set, and if so, just return. The end result should be less time spent on functional tests. It could also reduce occasional flakiness setting the time.