Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[8.x] [UA][Core] Surface integrations with internal APIs in upgrade a…
…ssistant (#199026) (#199764) # Backport This will backport the following commits from `main` to `8.x`: - [[UA][Core] Surface integrations with internal APIs in upgrade assistant (#199026)](#199026) <!--- Backport version: 8.9.8 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Ahmad Bamieh","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-12T11:19:22Z","message":"[UA][Core] Surface integrations with internal APIs in upgrade assistant (#199026)\n\n## Summary\r\n\r\n> In #117241 we're surfacing\r\nusage of APIs marked as `deprecated: true` in the Upgrade Assistant to\r\nhelp users prepare for a major upgrade. While internal APIs aren't\r\nreally deprecated in the same sense we are making a breaking change by\r\nblocking external integrations with these APIs. Since this could be\r\nequally disruptive to users depending on these APIs it would help our\r\nusers to surface such usage in the UA too.\r\n\r\nThe `api` deprecations now have two sub types:\r\n1. routes deprecations `options.deprecated: { … }`\r\n2. access deprecations `options.access: 'internal'`\r\n\r\nThis PR adds the second `api` deprecation subtype. The reason i kept one\r\n`api` deprecation type and i didnt create a new type is that they have\r\nexactly the same registration process but are triggered by different\r\nattributes. The `api` deprecation is fully managed by the core team\r\ninternal services and are configured by the user through the route\r\ninterface so it makes sense to keep them as one type. I also can see us\r\nadding more subtypes to this and just piggybacking on the current flow\r\ninstead of duplicating it everytime.\r\n\r\n\r\n**Checklist**\r\n- [x] Create deprecation subtype\r\n- [x] Example plugin\r\n- [x] Surface the deprecation in UA\r\n- [x] Api access deprecation copy (@florent-leborgne )\r\n- [x] Update README and code annotations\r\n- [x] Unit tests\r\n- [x] Integration tests\r\n\r\n\r\nCloses https://github.com/elastic/kibana/issues/194675\r\n\r\n### Design decisions:\r\nIf the API has both route deprecation (`options.deprecated: { … }` ) AND\r\nis an internal api `options.access: 'internal'`\r\n\r\nThe current behavior i went for in my PR:\r\nI show this API once in the UA under the internal access deprecation.\r\nWhile showing the route deprecation details if defined. This seems to\r\nmake the most sense since users should stop using this API altogether.\r\n\r\n### Copy decisions:\r\n@florent-leborgne wrote the copy for this deprecation subtype.\r\n<img width=\"1319\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/9a32f6d1-686a-4405-aec6-786ac5e10130\">\r\n\r\n<img width=\"713\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/1304c98d-4c64-468e-a7d6-19c1193bf678\">\r\n\r\n\r\n## Testing\r\n\r\nRun kibana locally with the test example plugin that has deprecated\r\nroutes\r\n```\r\nyarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples\r\n```\r\n\r\nThe following comprehensive deprecated routes examples are registered\r\ninside the folder:\r\n`examples/routing_example/server/routes/deprecated_routes`\r\n\r\nRun them in the dev console to trigger the deprecation condition so they\r\nshow up in the UA:\r\n\r\n```\r\nGET kbn:/api/routing_example/d/internal_deprecated_route?elasticInternalOrigin=false\r\nGET kbn:/internal/routing_example/d/internal_only_route?elasticInternalOrigin=false\r\nGET kbn:/internal/routing_example/d/internal_versioned_route?apiVersion=1&elasticInternalOrigin=false\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"a10eb1fe4e55aa0cfbbb4b12a8d740a867463283","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","backport:prev-minor","v8.17.0"],"number":199026,"url":"https://github.com/elastic/kibana/pull/199026","mergeCommit":{"message":"[UA][Core] Surface integrations with internal APIs in upgrade assistant (#199026)\n\n## Summary\r\n\r\n> In #117241 we're surfacing\r\nusage of APIs marked as `deprecated: true` in the Upgrade Assistant to\r\nhelp users prepare for a major upgrade. While internal APIs aren't\r\nreally deprecated in the same sense we are making a breaking change by\r\nblocking external integrations with these APIs. Since this could be\r\nequally disruptive to users depending on these APIs it would help our\r\nusers to surface such usage in the UA too.\r\n\r\nThe `api` deprecations now have two sub types:\r\n1. routes deprecations `options.deprecated: { … }`\r\n2. access deprecations `options.access: 'internal'`\r\n\r\nThis PR adds the second `api` deprecation subtype. The reason i kept one\r\n`api` deprecation type and i didnt create a new type is that they have\r\nexactly the same registration process but are triggered by different\r\nattributes. The `api` deprecation is fully managed by the core team\r\ninternal services and are configured by the user through the route\r\ninterface so it makes sense to keep them as one type. I also can see us\r\nadding more subtypes to this and just piggybacking on the current flow\r\ninstead of duplicating it everytime.\r\n\r\n\r\n**Checklist**\r\n- [x] Create deprecation subtype\r\n- [x] Example plugin\r\n- [x] Surface the deprecation in UA\r\n- [x] Api access deprecation copy (@florent-leborgne )\r\n- [x] Update README and code annotations\r\n- [x] Unit tests\r\n- [x] Integration tests\r\n\r\n\r\nCloses https://github.com/elastic/kibana/issues/194675\r\n\r\n### Design decisions:\r\nIf the API has both route deprecation (`options.deprecated: { … }` ) AND\r\nis an internal api `options.access: 'internal'`\r\n\r\nThe current behavior i went for in my PR:\r\nI show this API once in the UA under the internal access deprecation.\r\nWhile showing the route deprecation details if defined. This seems to\r\nmake the most sense since users should stop using this API altogether.\r\n\r\n### Copy decisions:\r\n@florent-leborgne wrote the copy for this deprecation subtype.\r\n<img width=\"1319\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/9a32f6d1-686a-4405-aec6-786ac5e10130\">\r\n\r\n<img width=\"713\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/1304c98d-4c64-468e-a7d6-19c1193bf678\">\r\n\r\n\r\n## Testing\r\n\r\nRun kibana locally with the test example plugin that has deprecated\r\nroutes\r\n```\r\nyarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples\r\n```\r\n\r\nThe following comprehensive deprecated routes examples are registered\r\ninside the folder:\r\n`examples/routing_example/server/routes/deprecated_routes`\r\n\r\nRun them in the dev console to trigger the deprecation condition so they\r\nshow up in the UA:\r\n\r\n```\r\nGET kbn:/api/routing_example/d/internal_deprecated_route?elasticInternalOrigin=false\r\nGET kbn:/internal/routing_example/d/internal_only_route?elasticInternalOrigin=false\r\nGET kbn:/internal/routing_example/d/internal_versioned_route?apiVersion=1&elasticInternalOrigin=false\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"a10eb1fe4e55aa0cfbbb4b12a8d740a867463283"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","labelRegex":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/199026","number":199026,"mergeCommit":{"message":"[UA][Core] Surface integrations with internal APIs in upgrade assistant (#199026)\n\n## Summary\r\n\r\n> In #117241 we're surfacing\r\nusage of APIs marked as `deprecated: true` in the Upgrade Assistant to\r\nhelp users prepare for a major upgrade. While internal APIs aren't\r\nreally deprecated in the same sense we are making a breaking change by\r\nblocking external integrations with these APIs. Since this could be\r\nequally disruptive to users depending on these APIs it would help our\r\nusers to surface such usage in the UA too.\r\n\r\nThe `api` deprecations now have two sub types:\r\n1. routes deprecations `options.deprecated: { … }`\r\n2. access deprecations `options.access: 'internal'`\r\n\r\nThis PR adds the second `api` deprecation subtype. The reason i kept one\r\n`api` deprecation type and i didnt create a new type is that they have\r\nexactly the same registration process but are triggered by different\r\nattributes. The `api` deprecation is fully managed by the core team\r\ninternal services and are configured by the user through the route\r\ninterface so it makes sense to keep them as one type. I also can see us\r\nadding more subtypes to this and just piggybacking on the current flow\r\ninstead of duplicating it everytime.\r\n\r\n\r\n**Checklist**\r\n- [x] Create deprecation subtype\r\n- [x] Example plugin\r\n- [x] Surface the deprecation in UA\r\n- [x] Api access deprecation copy (@florent-leborgne )\r\n- [x] Update README and code annotations\r\n- [x] Unit tests\r\n- [x] Integration tests\r\n\r\n\r\nCloses https://github.com/elastic/kibana/issues/194675\r\n\r\n### Design decisions:\r\nIf the API has both route deprecation (`options.deprecated: { … }` ) AND\r\nis an internal api `options.access: 'internal'`\r\n\r\nThe current behavior i went for in my PR:\r\nI show this API once in the UA under the internal access deprecation.\r\nWhile showing the route deprecation details if defined. This seems to\r\nmake the most sense since users should stop using this API altogether.\r\n\r\n### Copy decisions:\r\n@florent-leborgne wrote the copy for this deprecation subtype.\r\n<img width=\"1319\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/9a32f6d1-686a-4405-aec6-786ac5e10130\">\r\n\r\n<img width=\"713\" alt=\"image\"\r\nsrc=\"https://github.com/user-attachments/assets/1304c98d-4c64-468e-a7d6-19c1193bf678\">\r\n\r\n\r\n## Testing\r\n\r\nRun kibana locally with the test example plugin that has deprecated\r\nroutes\r\n```\r\nyarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples\r\n```\r\n\r\nThe following comprehensive deprecated routes examples are registered\r\ninside the folder:\r\n`examples/routing_example/server/routes/deprecated_routes`\r\n\r\nRun them in the dev console to trigger the deprecation condition so they\r\nshow up in the UA:\r\n\r\n```\r\nGET kbn:/api/routing_example/d/internal_deprecated_route?elasticInternalOrigin=false\r\nGET kbn:/internal/routing_example/d/internal_only_route?elasticInternalOrigin=false\r\nGET kbn:/internal/routing_example/d/internal_versioned_route?apiVersion=1&elasticInternalOrigin=false\r\n```\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine <[email protected]>","sha":"a10eb1fe4e55aa0cfbbb4b12a8d740a867463283"}},{"branch":"8.x","label":"v8.17.0","labelRegex":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Elastic Machine <[email protected]>
- Loading branch information