## Summary
This PR simplifies the weekly EUI upgrade and backport process by
conditionally aliasing `@elastic/eui` in shared deps webpack
configurations.
# Backstory
The EUI team (@elastic/eui-team) is responsible for keeping EUI up to
date in Kibana. Historically, this has been a relatively straightforward
(yet time-consuming) process, however, due to `8.x` backport
complexities caused by it using a different theme, it has become way
more demanding on everybody involved.
EUI is released on weekly basis. Each week, we release official EUI
versions tagged `latest` in npmjs and get a PR open that updates the
package in kibana `main`.
Our upgrade PRs tend to require anywhere between 2 and 25 codeowner
reviews due to the number of snapshots we need to update while working
on the EUI upgrade PRs. These snapshot changes are 99% of the time
harmless, yet it still takes 2+ full workdays to ping teams and get all
reviews necessary to get the PR merged. Generally speaking, we aim to
have the upgrade PR open on Monday and merged by Friday.
## The issue with `8.x` backports
Kibana 8.x uses the Amsterdam theme instead of Borealis, which is used
in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI
release we prepare another special Kibana 8.x only release of EUI (e.g.,
`101.2.0-amsterdam.0`). These special releases have the theme hardcoded
to Amsterdam at compile-time to avoid any initial theme errors Kibana
could otherwise experience. This is done primarily because some areas in
Kibana read EUI theme values outside of React components, and we have no
stable way to determine what the active theme is since there's no
context information. This is where we need to fall back to Amsterdam in
8.x and Borealis in 9.x.
**Since there are two different EUI versions - one for Kibana `main` and
9.0, and another for 8.x branches, we cannot use the automated backports
feature**. Instead, we open two separate PRs and configure backport
labels accordingly. Having two PRs is far from ideal since codeowners
need to review our changes twice, and we're more likely to make
mistakes.
# Our proposal
Following the recently introduced React version switching logic, we want
to conditionally switch between two `@elastic/eui` releases depending on
the kibana branch/version while keeping automated backports possible.
To achieve that, I added a dependency alias `@elastic/eui-amsterdam`
that points to the Amsterdam EUI release and configured `resolve.alias`
in shared deps to resolve the correct dependency based on the optional
`EUI_AMSTERDAM` environment variable. When this change is merged to
`main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to
the `8.19` branch updating the default value of `EUI_AMSTERDAM` to
`"true"`. This should result in no conflicts and be easy to follow.
Since 8.19 [uses the Amsterdam release of
`@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126)
(e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is
without `EUI_AMSTERDAM` configured beforehand.
## What does it change?
With this setup, we'll be able to update versions of `@elastic/eui` and
`@elastic/eui-amsterdam` at the same time in a single PR and make use of
automated kibana backports. There will be only one set of changes to
review by codeowners, and if there are any failing tests when
backporting to `8.19` due to, for example, changed color values, we can
follow the regular kibana procedures and fix them right in the created
backport PR. It'll simplify our workflow quite drastically while keeping
the same level of quality.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Updates `scripts/dependency_ownership` to use the
`@kbn/dev-cli-runner` for consistency with other CI-related CLIs.
- Adds a new `failIfUnowned` flag to exit with an error code if any
dependencies are unowned.
- Adds a new dependency ownership check to `quick_checks` and `renovate`
CI steps.
From a CI run, the additional quick check executes successfully in 3
seconds:
```sh
info [quick-checks] Passed check: /opt/buildkite-agent/builds/bk-agent-prod-gcp-abc123/elastic/kibana-pull-request/kibana/.buildkite/scripts/steps/checks/dependencies_missing_owner.sh in 3s
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR assigns owners for dependencies that are not yet claimed. These
assignments were a "best effort", and will likely need tweaking once
downstream teams start receiving renovate PRs.
## Summary
1. Show all packages owned by a specific team
```
node scripts/dependency_ownership -o <owner>
```
2. Identify owners of a specific dependency
```
node scripts/dependency_ownership -d <dependency>
```
3. List dependencies without an owner
```
node scripts/dependency_ownership --missing-owner
```
4. Generate a full dependency ownership report
```
node scripts/dependency_ownership
```
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
__Closes: https://github.com/elastic/kibana/issues/196767__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
