mirror of
https://github.com/elastic/kibana.git
synced 2025-06-27 18:51:07 -04:00
Updates Github link references from master to main (#116789)
Signed-off-by: Tyler Smalley <tyler.smalley@elastic.co>
This commit is contained in:
Tyler Smalley
GitHub
parent
2194f2b93c
commit
c4815d319e
123 changed files with 231 additions and 231 deletions
|
|
@ -29,7 +29,7 @@ Refer to [divio documentation](https://documentation.divio.com/) for guidance on
|
|||
|
||||
#### Location
|
||||
|
||||
If the information spans multiple plugins, consider adding it to the [dev_docs](https://github.com/elastic/kibana/tree/master/dev_docs) folder. If it is plugin specific, consider adding it inside the plugin folder. Write it in an mdx file if you would like it to show up in our new (beta) documentation system.
|
||||
If the information spans multiple plugins, consider adding it to the [dev_docs](https://github.com/elastic/kibana/tree/main/dev_docs) folder. If it is plugin specific, consider adding it inside the plugin folder. Write it in an mdx file if you would like it to show up in our new (beta) documentation system.
|
||||
|
||||
<DocCallOut title="internal only">
|
||||
|
||||
|
|
@ -139,7 +139,7 @@ export type foo: string | AnInterface;
|
|||
|
||||
### Example plugins
|
||||
|
||||
Running Kibana with `yarn start --run-examples` will include all [example plugins](https://github.com/elastic/kibana/tree/master/examples). These are tested examples of platform services in use. We strongly encourage anyone providing a platform level service or <DocLink id="kibBuildingBlocks" text="building block"/> to include a tutorial that links to a tested example plugin. This is better than relying on copied code snippets, which can quickly get out of date.
|
||||
Running Kibana with `yarn start --run-examples` will include all [example plugins](https://github.com/elastic/kibana/tree/main/examples). These are tested examples of platform services in use. We strongly encourage anyone providing a platform level service or <DocLink id="kibBuildingBlocks" text="building block"/> to include a tutorial that links to a tested example plugin. This is better than relying on copied code snippets, which can quickly get out of date.
|
||||
|
||||
## Performance
|
||||
|
||||
|
|
@ -165,7 +165,7 @@ all of our apps are accessible.
|
|||
|
||||
## Localization
|
||||
|
||||
Kibana is translated into other languages. Use our i18n utilities to ensure your public facing strings will be translated to ensure all Kibana apps are localized. Read and adhere to our [i18n guidelines](https://github.com/elastic/kibana/blob/master/packages/kbn-i18n/GUIDELINE.md)
|
||||
Kibana is translated into other languages. Use our i18n utilities to ensure your public facing strings will be translated to ensure all Kibana apps are localized. Read and adhere to our [i18n guidelines](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/GUIDELINE.md)
|
||||
|
||||
<DocCallOut title="Internal only">
|
||||
Elasticians, check out the #kibana-localization channel to ask questions and receive guidance.
|
||||
|
|
@ -173,7 +173,7 @@ Kibana is translated into other languages. Use our i18n utilities to ensure your
|
|||
|
||||
## Styleguide
|
||||
|
||||
We use es-lint rules when possible, but please review our [styleguide](https://github.com/elastic/kibana/blob/master/STYLEGUIDE.mdx), which includes recommendations that can't be linted on.
|
||||
We use es-lint rules when possible, but please review our [styleguide](https://github.com/elastic/kibana/blob/main/STYLEGUIDE.mdx), which includes recommendations that can't be linted on.
|
||||
|
||||
Es-lint overrides on a per-plugin level are discouraged.
|
||||
|
||||
|
|
@ -231,7 +231,7 @@ Consider how you want to handle the PR review. Reviewing each PR going into the
|
|||
|
||||
**3. Use an example plugin**
|
||||
|
||||
If you are building a service for developers, create an [example plugin](https://github.com/elastic/kibana/tree/master/examples) to showcase and test intended usage. This is a great way for reviewers and PMs to play around with a feature through the UI, before the production UI is ready. This can also help developers consuming your services get hands on.
|
||||
If you are building a service for developers, create an [example plugin](https://github.com/elastic/kibana/tree/main/examples) to showcase and test intended usage. This is a great way for reviewers and PMs to play around with a feature through the UI, before the production UI is ready. This can also help developers consuming your services get hands on.
|
||||
|
||||
## Embrace the monorepo
|
||||
|
||||
|
|
@ -241,7 +241,7 @@ When experimenting with code, it's completely fine to create a separate GitHub r
|
|||
|
||||
There are some exceptions where a separate repo makes sense. However, they are exceptions to the rule. A separate repo has proven beneficial when there's a dedicated team collaborating on a package which has multiple consumers, for example [EUI](https://github.com/elastic/eui).
|
||||
|
||||
It may be tempting to get caught up in the dream of writing the next package which is published to npm and downloaded millions of times a week. Knowing the quality of developers that are working on Kibana, this is a real possibility. However, knowing which packages will see mass adoption is impossible to predict. Instead of jumping directly to writing code in a separate repo and accepting all of the complications that come along with it, prefer keeping code inside the Kibana repo. A [Kibana package](https://github.com/elastic/kibana/tree/master/packages) can be used to publish a package to npm, while still keeping the code inside the Kibana repo. Move code to an external repo only when there is a good reason, for example to enable external contributions.
|
||||
It may be tempting to get caught up in the dream of writing the next package which is published to npm and downloaded millions of times a week. Knowing the quality of developers that are working on Kibana, this is a real possibility. However, knowing which packages will see mass adoption is impossible to predict. Instead of jumping directly to writing code in a separate repo and accepting all of the complications that come along with it, prefer keeping code inside the Kibana repo. A [Kibana package](https://github.com/elastic/kibana/tree/main/packages) can be used to publish a package to npm, while still keeping the code inside the Kibana repo. Move code to an external repo only when there is a good reason, for example to enable external contributions.
|
||||
|
||||
## Security best practices
|
||||
|
||||
|
|
|
|||
|
|
@ -11,59 +11,59 @@ A high-level walk through of the folder structure of our [repository](https://gi
|
|||
|
||||
Tip: Look for a `README.md` in a folder to learn about its contents.
|
||||
|
||||
## [.buildkite](https://github.com/elastic/kibana/tree/master/.buildkite)
|
||||
## [.buildkite](https://github.com/elastic/kibana/tree/main/.buildkite)
|
||||
|
||||
Managed by the operations team to set up a new buildkite ci system. Can be ignored by folks outside the Operations team.
|
||||
|
||||
## [.ci](https://github.com/elastic/kibana/tree/master/.ci)
|
||||
## [.ci](https://github.com/elastic/kibana/tree/main/.ci)
|
||||
|
||||
Managed by the operations team to contain Jenkins settings. Can be ignored by folks outside the Operations team.
|
||||
|
||||
## [.github](https://github.com/elastic/kibana/tree/master/.github)
|
||||
## [.github](https://github.com/elastic/kibana/tree/main/.github)
|
||||
|
||||
Contains GitHub configuration settings. This file contains issue templates, and the [CODEOWNERS](https://github.com/elastic/kibana/blob/master/.github/CODEOWNERS) file. It's important for teams to keep the CODEOWNERS file up-to-date so the right team is pinged for a code owner review on PRs that edit certain files. Note that the `CODEOWNERS` file only exists on the main/master branch, and is not backported to other branches in the repo.
|
||||
Contains GitHub configuration settings. This file contains issue templates, and the [CODEOWNERS](https://github.com/elastic/kibana/blob/main/.github/CODEOWNERS) file. It's important for teams to keep the CODEOWNERS file up-to-date so the right team is pinged for a code owner review on PRs that edit certain files. Note that the `CODEOWNERS` file only exists on the main/master branch, and is not backported to other branches in the repo.
|
||||
|
||||
## [api_docs](https://github.com/elastic/kibana/tree/master/api_docs)
|
||||
## [api_docs](https://github.com/elastic/kibana/tree/main/api_docs)
|
||||
|
||||
Every file in here is auto-generated by the <DocLink id="kibDevDocsApiWelcome" text="API Docs system"/> and used to render our API documentation. If you edit a public plugin or package API and run `node scripts/build_api_docs` you will see files changed in this folder. Do not edit the contents of this folder directly!
|
||||
|
||||
Note that currently you may see _a lot_ of changes because that command is not run on every PR and so the content in this folder is often outdated.
|
||||
|
||||
## [config](https://github.com/elastic/kibana/tree/master/config)
|
||||
## [config](https://github.com/elastic/kibana/tree/main/config)
|
||||
|
||||
This contains the base configuration file, `kibana.yml`. If you want to tweak any settings, create a `kibana.dev.yml` in here which will get picked up during development, and not checked into GitHub.
|
||||
|
||||
## [docs](https://github.com/elastic/kibana/tree/master/docs)
|
||||
## [docs](https://github.com/elastic/kibana/tree/main/docs)
|
||||
|
||||
Every folder in here _except_ the [development one](https://github.com/elastic/kibana/tree/master/docs/development) contains manually generated asciidocs that end up hosted in our [Elastic guide](https://www.elastic.co/guide/).
|
||||
Every folder in here _except_ the [development one](https://github.com/elastic/kibana/tree/main/docs/development) contains manually generated asciidocs that end up hosted in our [Elastic guide](https://www.elastic.co/guide/).
|
||||
|
||||
The `development` folder contains markdown that is auto-generated with our legacy API docs tool. We are aiming to remove it shortly after 8.0FF.
|
||||
|
||||
## [dev_docs](https://github.com/elastic/kibana/tree/master/dev_docs)
|
||||
## [dev_docs](https://github.com/elastic/kibana/tree/main/dev_docs)
|
||||
|
||||
This is where a lot of manually written content for our Developer Guide resides. Developers may also keep the information closer to what it's describing, but it's a good spot for high-level information, or information that describes how multiple plugins work together.
|
||||
|
||||
## [examples](https://github.com/elastic/kibana/tree/master/examples)
|
||||
## [examples](https://github.com/elastic/kibana/tree/main/examples)
|
||||
|
||||
These are our tested example plugins that also get built and hosted [here](https://demo.kibana.dev/8.0/app/developerExamples). If a plugin is written for testing purposes only, it won't go in here. These example plugins should be written with the intention of helping developers understand how to use our services.
|
||||
|
||||
## [legacy_rfcs](https://github.com/elastic/kibana/tree/master/legacy_rfcs)
|
||||
## [legacy_rfcs](https://github.com/elastic/kibana/tree/main/legacy_rfcs)
|
||||
|
||||
We used to write RFCs in `md` format and keep them in the repository, but we have since moved to Google Docs. We kept the folder around, since some folks still read these old docs. If you are an internal contributor you can visit <DocLink id="ktRFCProcess" text="this document"/> to read about our current RFC process.
|
||||
|
||||
## [licenses](https://github.com/elastic/kibana/tree/master/licenses)
|
||||
## [licenses](https://github.com/elastic/kibana/tree/main/licenses)
|
||||
|
||||
Contains our two license header texts, one for the Elastic license and one for the Elastic+SSPL license. All code files inside x-pack should have the Elastic license text at the top, all code files outside x-pack should contain the other. If you have your environment set up to auto-fix on save, eslint should take care of adding it for you. If you don't have it, ci will fail. Can be ignored for the most part, this rarely changes.
|
||||
|
||||
## [packages](https://github.com/elastic/kibana/tree/master/packages)
|
||||
## [packages](https://github.com/elastic/kibana/tree/main/packages)
|
||||
|
||||
The packages folder contains a mixture of build-time related code (like the [code needed to build the api docs](https://github.com/elastic/kibana/tree/master/packages/kbn-docs-utils)), as well as static code that some plugins rely on (like the [kbn-monaco package](https://github.com/elastic/kibana/tree/master/packages/kbn-monaco)). <DocLink id="kibPlatformIntro" section="1000-foot-view" text="This document"/> covers how packages differ from plugins.
|
||||
The packages folder contains a mixture of build-time related code (like the [code needed to build the api docs](https://github.com/elastic/kibana/tree/main/packages/kbn-docs-utils)), as well as static code that some plugins rely on (like the [kbn-monaco package](https://github.com/elastic/kibana/tree/main/packages/kbn-monaco)). <DocLink id="kibPlatformIntro" section="1000-foot-view" text="This document"/> covers how packages differ from plugins.
|
||||
|
||||
## [plugins](https://github.com/elastic/kibana/tree/master/plugins)
|
||||
## [plugins](https://github.com/elastic/kibana/tree/main/plugins)
|
||||
|
||||
This is an empty folder in GitHub. It's where third party developers should put their plugin folders. Internal developers can ignore this folder.
|
||||
|
||||
## [scripts](https://github.com/elastic/kibana/tree/master/scripts)
|
||||
## [scripts](https://github.com/elastic/kibana/tree/main/scripts)
|
||||
|
||||
Contains a bunch of developer scripts. These are usually very small files with just two lines that kick off a command, the logic of which resides elsewhere (sometimes `src/dev`, sometimes inside `packages`).
|
||||
Example:
|
||||
|
|
@ -72,65 +72,65 @@ require('../src/setup_node_env');
|
|||
require('@kbn/es-archiver').runCli();
|
||||
```
|
||||
|
||||
## [src](https://github.com/elastic/kibana/tree/master/src)
|
||||
## [src](https://github.com/elastic/kibana/tree/main/src)
|
||||
|
||||
This folder and the packages folder contain the most code and where developers usually find themselves. I'll touch on a few of the subfolder, the rest can generally be ignored, or are build/ops related code.
|
||||
|
||||
### [src/cli*](https://github.com/elastic/kibana/tree/master/src/cli)
|
||||
### [src/cli*](https://github.com/elastic/kibana/tree/main/src/cli)
|
||||
|
||||
Maintained primarily by the Operations team, this folder contains code that initializes the Kibana runtime and a bit of work to handle authorization for interactive setup mode. Most devs should be able to ignore this code.
|
||||
|
||||
### [src/core](https://github.com/elastic/kibana/tree/master/src/core)
|
||||
### [src/core](https://github.com/elastic/kibana/tree/main/src/core)
|
||||
|
||||
This code primarily belongs to the Core team and contains the plugin infrastructure, as well as a bunch of fundamental services like migrations, saved objects, and some UI utilities (toasts, flyouts, etc.).
|
||||
|
||||
### [src/dev](https://github.com/elastic/kibana/tree/master/src/dev)
|
||||
### [src/dev](https://github.com/elastic/kibana/tree/main/src/dev)
|
||||
|
||||
Maintained by the Operations team, this code contains build and development tooling related code. This folder existed before `packages`, so contains mostly older code that hasn't been migrated to packages. Prefer creating a `package` if possible. Can be ignored for the most part if you are not on the Ops team. Prefer
|
||||
|
||||
### [src/plugins](https://github.com/elastic/kibana/tree/master/src/plugins)
|
||||
### [src/plugins](https://github.com/elastic/kibana/tree/main/src/plugins)
|
||||
|
||||
Contains all of our Basic-licensed plugins. Most folders in this directory will contain `README.md` files explaining what they do. If there are none, you can look at the `owner.gitHub` field inside all `kibana.json`s that will tell you which team to get in touch with for questions.
|
||||
|
||||
Note that as plugins can be nested, each folder in this directory may contain multiple plugins.
|
||||
|
||||
## [test](https://github.com/elastic/kibana/tree/master/test)
|
||||
## [test](https://github.com/elastic/kibana/tree/main/test)
|
||||
|
||||
Contains functional tests and related FTR (functional test runner) code for the plugins inside `src/plugins`, although there is a push to move the tests to reside inside the plugins themselves.
|
||||
|
||||
## [typings](https://github.com/elastic/kibana/tree/master/typings)
|
||||
## [typings](https://github.com/elastic/kibana/tree/main/typings)
|
||||
|
||||
Maintained by Ops and Core, this contains global typings for dependencies that do not provide their own types, or don't have types available via [DefinitelyTyped](https://definitelytyped.org). This directory is intended to be minimal; types should only be added here as a last resort.
|
||||
|
||||
## [vars](https://github.com/elastic/kibana/tree/master/vars)
|
||||
## [vars](https://github.com/elastic/kibana/tree/main/vars)
|
||||
|
||||
A bunch of groovy scripts maintained by the Operations team.
|
||||
|
||||
## [x-pack](https://github.com/elastic/kibana/tree/master/x-pack)
|
||||
## [x-pack](https://github.com/elastic/kibana/tree/main/x-pack)
|
||||
|
||||
Contains all code and infrasturcture that powers our gold+ (non-basic) features that are provided under a more restrictive license.
|
||||
|
||||
### [x-pack/build_chromium](https://github.com/elastic/kibana/tree/master/x-pack/build_chromium)
|
||||
### [x-pack/build_chromium](https://github.com/elastic/kibana/tree/main/x-pack/build_chromium)
|
||||
|
||||
Maintained by the App Services UX team, this contains Reporting-related code for building Chromium in order to take server side screenshots.
|
||||
|
||||
### [x-pack/dev-tools](https://github.com/elastic/kibana/tree/master/x-pack/dev-tools)
|
||||
### [x-pack/dev-tools](https://github.com/elastic/kibana/tree/main/x-pack/dev-tools)
|
||||
|
||||
Maintained by the Operations team.
|
||||
|
||||
### [x-pack/examples](https://github.com/elastic/kibana/tree/master/x-pack/examples)
|
||||
### [x-pack/examples](https://github.com/elastic/kibana/tree/main/x-pack/examples)
|
||||
|
||||
Contains all example plugins that rely on gold+ features.
|
||||
|
||||
### [x-pack/plugins](https://github.com/elastic/kibana/tree/master/x-pack/plugins)
|
||||
### [x-pack/plugins](https://github.com/elastic/kibana/tree/main/x-pack/plugins)
|
||||
|
||||
Contains code for all the plugins that power our gold+ features.
|
||||
|
||||
### [x-pack/scripts](https://github.com/elastic/kibana/tree/master/x-pack/scripts)
|
||||
### [x-pack/scripts](https://github.com/elastic/kibana/tree/main/x-pack/scripts)
|
||||
|
||||
Maintained by the Ops team, this folder contains some scripts for running x-pack utilities, like the functional test runner that runs with a license higher than Basic.
|
||||
|
||||
### [x-pack/test](https://github.com/elastic/kibana/tree/master/x-pack/test)
|
||||
### [x-pack/test](https://github.com/elastic/kibana/tree/main/x-pack/test)
|
||||
|
||||
Functional tests for our gold+ features.
|
||||
|
||||
|
|
|
|||
|
|
@ -69,6 +69,6 @@ Every team should be collecting telemetry metrics on it’s public API usage. Th
|
|||
|
||||
### Documentation
|
||||
|
||||
Every public API should be documented inside the [docs/api](https://github.com/elastic/kibana/tree/master/docs/api) folder in asciidoc (this content will eventually be migrated to mdx to support the new docs system). If a public REST API is undocumented, you should either document it, or make it internal.
|
||||
Every public API should be documented inside the [docs/api](https://github.com/elastic/kibana/tree/main/docs/api) folder in asciidoc (this content will eventually be migrated to mdx to support the new docs system). If a public REST API is undocumented, you should either document it, or make it internal.
|
||||
|
||||
Every public API should have a release tag specified using the appropriate documentation release tag above. If you do this, the docs system will provide a pop up explaining the conditions. If an API is not marked, it should be considered experimental.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue