|
| 1 | +# Integrations Manager |
| 2 | + |
| 3 | +## Development |
| 4 | +### Branch |
| 5 | +We're using a long-running feature branch [`feature-integrations-manager`](https://github.com/elastic/kibana/tree/feature-integrations-manager). |
| 6 | + |
| 7 | +<details> |
| 8 | + <summary>Keeping up to date with upstream kibana</summary> |
| 9 | + |
| 10 | +```bash |
| 11 | +## checkout feature branch to your fork |
| 12 | +git checkout -B feature-integrations-manager origin/feature-integrations-manager |
| 13 | + |
| 14 | +## make sure your feature branch is current with upstream feature branch |
| 15 | +git pull upstream feature-integrations-manager |
| 16 | + |
| 17 | +## pull in changes from upstream master |
| 18 | +git pull upstream master |
| 19 | + |
| 20 | +## push changes to your remote |
| 21 | +git push origin |
| 22 | + |
| 23 | +# Open a **DRAFT PR**. Normal PRs will re-notify authors of commits already merged |
| 24 | +# Draft PR will trigger CI run. Once CI is green ... |
| 25 | + |
| 26 | +## push your changes to upstream feature branch |
| 27 | +git push upstream |
| 28 | +``` |
| 29 | +</details> |
| 30 | + |
| 31 | +### Feature development |
| 32 | +In your own fork of `elastic/kibana`, create a feature branch based on `feature-integrations-manager`. |
| 33 | + |
| 34 | +``` |
| 35 | +git checkout -b 1234-feature-description feature-integrations-manager |
| 36 | +# ... git commits for feature |
| 37 | +open https://github.com/elastic/kibana/compare/feature-integrations-manager...yourgithubname:1234-feature-description |
| 38 | +``` |
| 39 | + |
| 40 | +See https://github.com/elastic/kibana/pull/37950 for an example. |
| 41 | + |
| 42 | +### Getting started |
| 43 | +See the Kibana docs for [how to set up your dev environment](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#setting-up-your-development-environment), [run Elasticsearch](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#running-elasticsearch), and [start Kibana](https://github.com/elastic/kibana/blob/master/CONTRIBUTING.md#running-kibana). |
| 44 | + |
| 45 | +One common workflow is: |
| 46 | + 1. `yarn es snapshot` |
| 47 | + 1. In another shell: `yarn start --no-base-path` |
| 48 | + |
| 49 | +### Plugin architecture |
| 50 | +Follows the `common`, `server`, `public` structure from the [Architecture Style Guide |
| 51 | +](https://github.com/elastic/kibana/blob/master/style_guides/architecture_style_guide.md#file-and-folder-structure). |
| 52 | + |
| 53 | +We use New Platform approach (structure, APIs, etc) where possible. There's a `kibana.json` manifest, and the server uses the `server/{index,plugin}.ts` approach from [`MIGRATION.md`](https://github.com/elastic/kibana/blob/master/src/core/MIGRATION.md#architecture). The client code we author is using New Platform shape & APIs, but the Manager deals with external systems which are at their own stages of migration. |
0 commit comments