Skip to content

Commit

Permalink
Merge branch 'lens/dynamic-coloring-table' of github.com:dej611/kiban…
Browse files Browse the repository at this point in the history
…a into lens/dynamic-coloring-table
  • Loading branch information
dej611 committed May 26, 2021
2 parents c3c4bf0 + 58e5998 commit b18be4e
Show file tree
Hide file tree
Showing 623 changed files with 9,727 additions and 7,052 deletions.
129 changes: 84 additions & 45 deletions api_docs/alerting.json

Large diffs are not rendered by default.

Binary file added dev_docs/assets/kibana_template_solution_nav.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
135 changes: 135 additions & 0 deletions dev_docs/tutorials/building_a_kibana_distributable.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,135 @@
---
id: kibDevTutorialBuildingDistributable
slug: /kibana-dev-docs/tutorial/building-distributable
title: Building a Kibana distributable
summary: Learn how to build a Kibana distributable
date: 2021-05-10
tags: ['kibana', 'onboarding', 'dev', 'tutorials', 'build', 'distributable']
---

On the course of that tutorial it will be possible to learn more about how we can create a Kibana distributable
as well as handle its different main configurations.

At any given point, you can get CLI help running the following command:

```bash
yarn build --help
```

## Prerequisites

For the basic steps of the build we only require you to use one of the following operating systems:

- Linux
- macOS

However if as part of the build you also want to generate Linux installation packages (deb, rpm) or Docker images there
are other dependencies to have in mind as those installation packages and Docker images generation are run using fpm, dpkg, rpm, and Docker.

### For Linux Installation Packages Build

Please make sure you have the following dependencies installed:

#### Install FPM dependencies

**On OSX/macOS:**

```bash
brew install gnu-tar rpm
```

**On Red Hat systems (Fedora 22 or older, CentOS, etc):**

```bash
yum install ruby-devel gcc make rpm-build rubygems
```

**On Fedora 23 or newer:**

```bash
dnf install ruby-devel gcc make rpm-build libffi-devel
```

**On Oracle Linux 7.x systems:**

```bash
yum-config-manager --enable ol7_optional_latest
yum install ruby-devel gcc make rpm-build rubygems
```

**On Debian-derived systems (Debian, Ubuntu, etc):**

```bash
apt-get install ruby ruby-dev rubygems build-essential
```

#### Install FPM

Finally install fpm with the gem tool with:

```bash
gem install fpm -v 1.5.0
```

### For Docker Images Build

For Docker, the installation instructions can be found at [Install Docker Engine](https://docs.docker.com/engine/install/).


## Create a Kibana distributable

In a great majority of the use cases where we need to build a Kibana distributable, we just need the archives containing the
node executable and the bundled code of the application.

By doing that Linux installation packages and Docker images will be excluded and as a result, the build will be quicker.

We can do it by simply running:

```bash
yarn build --skip-os-packages
```

Note that we used `--skip-os-packages` which will skip the OS packages build.

> In case you are testing something and running that same command a couple of times, `--skip-node-download` can be used
to speed up the process by a little.

At the end of the process a Kibana distributable was created in a `target` folder created relative to your repository checkout.
The folder will look like the following:

![Target Folder Outlook With a Kibana Distributable](../assets/target_folder_with_simple_kibana_distributable.png)

## Controlling the log levels

By default, when building the distributable, the `debug` log level will be used across all the steps.
That default setting should give us a good amount of information about the tasks being done.

To turn it off you can run the build along `--no-debug` flag. At that point that information will no longer be printed out.

For a longer and verbose logging than `debug` there is other option that can be passed along the build command which is `--verbose`.

## Create a Kibana distributable with Linux installation packages and Docker images

If you comply with every prerequisite and dependency listed above, then there is also the option to create a Kibana distributable along with
Linux installation packages like rpm and deb or Docker images.

To achieve it, you can run:

```bash
yarn build
```

At the end you will get the Kibana distributable archives plus the Docker images and both an rpm and a deb package.

To specify just a single installation package or Docker images to build instead of all of them you can add rpm, deb or docker-images as an argument:

```bash
yarn build --deb
yarn build --rpm
yarn build --docker-images
```

Again the distributable contents resulting from running the build command can be found in a `target` folder created relative to the repository after the build completes.
It will look something like:

![Target Folder Outlook With a Kibana Distributable And OS Packages](../assets/target_folder_with_a_kibana_distributable_and_os_packages.png)
37 changes: 35 additions & 2 deletions dev_docs/tutorials/kibana_page_template.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -9,13 +9,13 @@ tags: ['kibana', 'dev', 'ui', 'tutorials']

`KibanaPageTemplate` is a thin wrapper around [EuiPageTemplate](https://elastic.github.io/eui/#/layout/page) that makes setting up common types of Kibana pages quicker and easier while also adhering to any Kibana-specific requirements and patterns.

Refer to EUI's documentation on [EuiPageTemplate](https://elastic.github.io/eui/#/layout/page) for constructing page layouts.
Refer to EUI's documentation on [**EuiPageTemplate**](https://elastic.github.io/eui/#/layout/page) for constructing page layouts.

## `isEmptyState`

Use the `isEmptyState` prop for when there is no page content to show. For example, before the user has created something, when no search results are found, before data is populated, or when permissions aren't met.

The default empty state uses any `pageHeader` info provided to populate an [`EuiEmptyPrompt`](https://elastic.github.io/eui/#/display/empty-prompt) and uses the `centeredBody` template type.
The default empty state uses any `pageHeader` info provided to populate an [**EuiEmptyPrompt**](https://elastic.github.io/eui/#/display/empty-prompt) and uses the `centeredBody` template type.

```tsx
<KibanaPageTemplate
Expand Down Expand Up @@ -84,3 +84,36 @@ When passing both a `pageHeader` configuration and `isEmptyState`, the component
```

![Screenshot of demo custom empty state code with a page header. Shows the Kibana navigation bars, a level 1 heading "Dashboards", and a centered empty state with the a level 2 heading "No data", body text "You have no data. Would you like some of ours?", and a button that says "Get sample data".](../assets/kibana_header_and_empty_state.png)

## `solutionNav`

To add left side navigation for your solution, we recommend passing [**EuiSideNav**](https://elastic.github.io/eui/#/navigation/side-nav) props to the `solutionNav` prop. The template component will then handle the mobile views and add the solution nav embellishments. On top of the EUI props, you'll need to pass your solution `name` and an optional `icon`.

If you need to custom side bar content, you will need to pass you own navigation component to `pageSideBar`. We still recommend using [**EuiSideNav**](https://elastic.github.io/eui/#/navigation/side-nav).

When using `EuiSideNav`, root level items should not be linked but provide section labelling only.

```tsx
<KibanaPageTemplate
solutionNav={{
name: 'Management',
icon: 'managementApp',
items: [
{
name: 'Root item',
items: [
{ name: 'Navigation item', href: '#' },
{ name: 'Navigation item', href: '#' },
]
}
]
}}
>
{...}
</KibanaPageTemplate>
```


![Screenshot of Stack Management empty state with a provided solution navigation shown on the left, outlined in pink.](../assets/kibana_template_solution_nav.png)

![Screenshots of Stack Management page in mobile view. Menu closed on the left, menu open on the right.](../assets/kibana_template_solution_nav_mobile.png)
1 change: 1 addition & 0 deletions docs/concepts/index.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -87,6 +87,7 @@ image:concepts/images/refresh-every.png["section of time filter where you can co


[float]
[[semi-structured-search]]
==== Semi-structured search

Combine free text search with field-based search using the Kibana Query Language (KQL).
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -139,11 +139,14 @@ export default function (/* { providerAPI } */) {
}
-----------

**Services**:::
Services are named singleton values produced by a Service Provider. Tests and other services can retrieve service instances by asking for them by name. All functionality except the mocha API is exposed via services.
**Service**:::
A Service is a named singleton created using a subclass of `FtrService`. Tests and other services can retrieve service instances by asking for them by name. All functionality except the mocha API is exposed via services. When you write your own functional tests check for existing services that help with the interactions you're looking to execute, and add new services for interactions which aren't already encoded in a service.

**Service Providers**:::
For legacy purposes, and for when creating a subclass of `FtrService` is inconvenient, you can also create services using a "Service Provider". These are functions which which create service instances and return them. These instances are cached and provided to tests. Currently these providers may also return a Promise for the service instance, allowing the service to do some setup work before tests run. We expect to fully deprecate and remove support for async service providers in the near future and instead require that services use the `lifecycle` service to run setup before tests. Providers which return instances of classes other than `FtrService` will likely remain supported for as long as possible.

**Page objects**:::
Page objects are a special type of service that encapsulate behaviors common to a particular page or plugin. When you write your own plugin, you’ll likely want to add a page object (or several) that describes the common interactions your tests need to execute.
Page objects are functionally equivalent to services, except they are loaded with a slightly different mechanism and generally defined separate from services. When you write your own functional tests you might want to write some of your services as Page objects, but it is not required.

**Test Files**:::
The `FunctionalTestRunner`'s primary purpose is to execute test files. These files export a Test Provider that is called with a Provider API but is not expected to return a value. Instead Test Providers define a suite using https://mochajs.org/#bdd[mocha's BDD interface].
Expand Down
2 changes: 1 addition & 1 deletion docs/developer/getting-started/monorepo-packages.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -82,13 +82,13 @@ yarn kbn watch-bazel
- @kbn/i18n
- @kbn/legacy-logging
- @kbn/logging
- @kbn/securitysolution-constants
- @kbn/securitysolution-es-utils
- kbn/securitysolution-io-ts-alerting-types
- kbn/securitysolution-io-ts-list-types
- kbn/securitysolution-io-ts-types
- @kbn/securitysolution-io-ts-utils
- @kbn/securitysolution-list-api
- @kbn/securitysolution-list-constants
- @kbn/securitysolution-list-hooks
- @kbn/securitysolution-list-utils
- @kbn/securitysolution-utils
Expand Down
2 changes: 1 addition & 1 deletion docs/developer/plugin-list.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -321,7 +321,7 @@ which will load the visualization's editor.
|{kib-repo}blob/{branch}/x-pack/plugins/alerting/README.md[alerting]
|The Kibana alerting plugin provides a common place to set up alerts. You can:
|The Kibana Alerting plugin provides a common place to set up rules. You can:
|{kib-repo}blob/{branch}/x-pack/plugins/apm/readme.md[apm]
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
<!-- Do not edit this file. It is automatically generated by API Documenter. -->

[Home](./index.md) &gt; [kibana-plugin-core-public](./kibana-plugin-core-public.md) &gt; [App](./kibana-plugin-core-public.app.md) &gt; [deepLinks](./kibana-plugin-core-public.app.deeplinks.md)

## App.deepLinks property

Input type for registering secondary in-app locations for an application.

Deep links must include at least one of `path` or `deepLinks`<!-- -->. A deep link that does not have a `path` represents a topological level in the application's hierarchy, but does not have a destination URL that is user-accessible.

<b>Signature:</b>

```typescript
deepLinks?: AppDeepLink[];
```

## Example


```ts
core.application.register({
id: 'my_app',
title: 'Translated title',
keywords: ['translated keyword1', 'translated keyword2'],
deepLinks: [
{ id: 'sub1', title: 'Sub1', path: '/sub1', keywords: ['subpath1'] },
{
id: 'sub2',
title: 'Sub2',
deepLinks: [
{ id: 'subsub', title: 'SubSub', path: '/sub2/sub', keywords: ['subpath2'] }
]
}
],
mount: () => { ... }
})

```

Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
<!-- Do not edit this file. It is automatically generated by API Documenter. -->

[Home](./index.md) &gt; [kibana-plugin-core-public](./kibana-plugin-core-public.md) &gt; [App](./kibana-plugin-core-public.app.md) &gt; [keywords](./kibana-plugin-core-public.app.keywords.md)

## App.keywords property

Optional keywords to match with in deep links search. Omit if this part of the hierarchy does not have a page URL.

<b>Signature:</b>

```typescript
keywords?: string[];
```
Original file line number Diff line number Diff line change
Expand Up @@ -19,12 +19,13 @@ export interface App<HistoryLocationState = unknown>
| [capabilities](./kibana-plugin-core-public.app.capabilities.md) | <code>Partial&lt;Capabilities&gt;</code> | Custom capabilities defined by the app. |
| [category](./kibana-plugin-core-public.app.category.md) | <code>AppCategory</code> | The category definition of the product See [AppCategory](./kibana-plugin-core-public.appcategory.md) See DEFAULT\_APP\_CATEGORIES for more reference |
| [chromeless](./kibana-plugin-core-public.app.chromeless.md) | <code>boolean</code> | Hide the UI chrome when the application is mounted. Defaults to <code>false</code>. Takes precedence over chrome service visibility settings. |
| [deepLinks](./kibana-plugin-core-public.app.deeplinks.md) | <code>AppDeepLink[]</code> | Input type for registering secondary in-app locations for an application.<!-- -->Deep links must include at least one of <code>path</code> or <code>deepLinks</code>. A deep link that does not have a <code>path</code> represents a topological level in the application's hierarchy, but does not have a destination URL that is user-accessible. |
| [defaultPath](./kibana-plugin-core-public.app.defaultpath.md) | <code>string</code> | Allow to define the default path a user should be directed to when navigating to the app. When defined, this value will be used as a default for the <code>path</code> option when calling [navigateToApp](./kibana-plugin-core-public.applicationstart.navigatetoapp.md)<!-- -->\`<!-- -->, and will also be appended to the [application navLink](./kibana-plugin-core-public.chromenavlink.md) in the navigation bar. |
| [euiIconType](./kibana-plugin-core-public.app.euiicontype.md) | <code>string</code> | A EUI iconType that will be used for the app's icon. This icon takes precendence over the <code>icon</code> property. |
| [exactRoute](./kibana-plugin-core-public.app.exactroute.md) | <code>boolean</code> | If set to true, the application's route will only be checked against an exact match. Defaults to <code>false</code>. |
| [icon](./kibana-plugin-core-public.app.icon.md) | <code>string</code> | A URL to an image file used as an icon. Used as a fallback if <code>euiIconType</code> is not provided. |
| [id](./kibana-plugin-core-public.app.id.md) | <code>string</code> | The unique identifier of the application |
| [meta](./kibana-plugin-core-public.app.meta.md) | <code>AppMeta</code> | Meta data for an application that represent additional information for the app. See [AppMeta](./kibana-plugin-core-public.appmeta.md) |
| [keywords](./kibana-plugin-core-public.app.keywords.md) | <code>string[]</code> | Optional keywords to match with in deep links search. Omit if this part of the hierarchy does not have a page URL. |
| [mount](./kibana-plugin-core-public.app.mount.md) | <code>AppMount&lt;HistoryLocationState&gt;</code> | A mount function called when the user navigates to this app's route. |
| [navLinkStatus](./kibana-plugin-core-public.app.navlinkstatus.md) | <code>AppNavLinkStatus</code> | The initial status of the application's navLink. Defaulting to <code>visible</code> if <code>status</code> is <code>accessible</code> and <code>hidden</code> if status is <code>inaccessible</code> See [AppNavLinkStatus](./kibana-plugin-core-public.appnavlinkstatus.md) |
| [order](./kibana-plugin-core-public.app.order.md) | <code>number</code> | An ordinal used to sort nav links relative to one another for display. |
Expand Down
43 changes: 0 additions & 43 deletions docs/development/core/public/kibana-plugin-core-public.app.meta.md

This file was deleted.

Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
<!-- Do not edit this file. It is automatically generated by API Documenter. -->

[Home](./index.md) &gt; [kibana-plugin-core-public](./kibana-plugin-core-public.md) &gt; [AppDeepLink](./kibana-plugin-core-public.appdeeplink.md)

## AppDeepLink type

Input type for registering secondary in-app locations for an application.

Deep links must include at least one of `path` or `deepLinks`<!-- -->. A deep link that does not have a `path` represents a topological level in the application's hierarchy, but does not have a destination URL that is user-accessible.

<b>Signature:</b>

```typescript
export declare type AppDeepLink = {
id: string;
title: string;
keywords?: string[];
navLinkStatus?: AppNavLinkStatus;
} & ({
path: string;
deepLinks?: AppDeepLink[];
} | {
path?: string;
deepLinks: AppDeepLink[];
});
```

This file was deleted.

Loading

0 comments on commit b18be4e

Please sign in to comment.