[Archive Migration] dashboard/current/kibana

[LeeDr]

Summary

This PR replaces test/functional/fixtures/es_archiver/dashboard/current/kibana with test/functional/fixtures/kbn_archiver/dashboard/current/kibana which impacts quite a few tests.

A couple of interesting notes about this PR and the original es_archive.

1. The original es_archive included some visualizations which referenced index patterns which were purposely removed for some tests. To create the kbn_archive, I load the es_archive and then save the kbn_archive. But this new kbn_archive won't load because loading saved objects checks references and 2 are missing. So I had to add 2 index patterns with the ids of the missing references, and then create another kbn_archive with only those 2 index patterns so some tests could unload them. I tried to only unload those in the tests which relied on them being missing. I also added a comment in those places.
2. I want to backport these kbn_archive migration PRs back to 7.17 so I originally created it from that version. But it turns out that there was another change to this es_archive between 7.17 and 8.0. So my last commit of the kbn_archive was created from 8.0 instead, and I'll have to modify the 7.17 backport PR to use the right one.
3. Cleaning - while loading an es_archive to the .kibana index would wipe out all existing Saved Objects, kibanaServer.importExport.load doesn't do that. So to eliminate interference from prior tests I added the kibanaServer.savedObjects.clean({ types: ['search', 'index-pattern', 'visualization', 'dashboard'], }); before the load, and in the after method (I had to add an after method to some tests). There really are a few other types that can. and perhaps should, be cleaned such as lens and maps. Maybe we need a cleanAll method to simplify this.

[LeeDr]

@elasticmachine merge upstream

[spalger]

I would greatly prefer that we don't try to define a "standard list" of types to cleanup in the kbn_client, or that we have a kbnArchive that is just for unloading. I'd like to propose that instead we create a "data scenarios" service for dashboard which has these defaults for the dashboard tests. I've started a PR showing what I mean here: LeeDr#4

Discussed with @LeeDr and we should stick with what we have for now

[LeeDr]

@elasticmachine merge upstream

[ThomThomson]

Looked through the code changes and everything here makes sense. I especially appreciated your explanations of the cleanStandardList function, and the explanations of the two removed index patterns.

Thank you for doing this! Changes LGTM

[LeeDr]

@elasticmachine merge upstream

[LeeDr]

I'm not sure what happened on that last run?

You can still download the full log using the "Download" button above.
--
  | ... |  
  | $ node scripts/jest --config src/plugins/kibana_usage_collection/jest.integration.config.js | 18s
  | $ node scripts/jest --config x-pack/plugins/fleet/jest.integration.config.js | 15m 8s
  | $ node scripts/jest --config x-pack/plugins/reporting/jest.integration.config.js | 35s
  | # Received cancellation signal, interrupting
  | 🚨 Error: The command was interrupted by a signal

[LeeDr]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: ebd8bec
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

✅ unchanged

History

• 💔 Build #28621 failed ccb9780
• 💛 Build #28569 was flaky 3e7d74b
• 💔 Build #28468 failed 284dbd2
• 💚 Build #28182 succeeded 64ae171
• 💔 Build #28131 failed 7f0e9eb

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[kibanamachine]

💔 Some backports could not be created

Status	Branch	Result
✅	8.1
❌	7.17	Backport failed because of merge conflicts
❌	8.0	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 126293

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation