Skip to content

Latest commit

 

History

History
32 lines (19 loc) · 2.11 KB

CONTRIBUTE.md

File metadata and controls

32 lines (19 loc) · 2.11 KB

Getting started

A data source backend plugin consists of both frontend (TypeScript) and backend (Golang) components. A TypeScript development environment and a Golang one are needed in order to work over that plugin. For more technical information about backend plugins, refer to the documentation on Backend plugins.

Development environment

The unified development environment is built atop Docker containers, composed with Docker Compose. It provides a running Druid instance, a running Grafana instance (use druid/druid as username/password to login), and a builder container. You, only, gonna need to install Compose (See https://docs.docker.com/compose/install).

Any "building" is done within the builder container (that saves you from setting up Node and Golang development environments on your host).

Mage (See https://magefile.org) is used in order to run commands over that environment (mostly within that builder container).

If you don't want to run commands in that development environment container, you can set the environment variable GRAFADRUID_USE_DOCKER=0 and the commands will be run against your host.

In the same "plug & play" spirit, Mage is provided as a binary so you don't have have to install it locally.

  • To start the environment, run: ./mage env:start
  • To stop the environment, run: ./mage env:stop

Once the env is started (with ./mage env:start) you can build plugin parts or the whole plugin:

  • To build frontend part of the plugin, run ./mage frontend:build
  • To build backend part of the plugin, run ./mage backend:build
  • To build the whole plugin, run ./mage buildAll (or simply, ./mage)

Few more targets are available (tests, cleanup, ...), you can list them all with ./mage -l.

If you update Magefile.go, you could use ./mage env:updateMage in order to update the mage binary.

Beware the sdk:* (provided by Grafana backend plugin SDK) targets won't run within the container, but directly on the host; those commands are exactly the ones proxied thru the builder container thru the backend:* targets