Files
karma/CONTRIBUTING.md
Łukasz Mierzwa d1a101a416 chore(ui): migrate from npm to yarn
Everyone seems to support it, doesn't have same lock file generation issues, let's try it
2018-10-02 23:02:50 +01:00

2.6 KiB

Contributing to karma

Getting Started

To get started follow Building from source section of the README file.

Git tags and branches

Every release tag name will follow vX.Y.Z naming scheme, example: v0.1.0. Every release tree has a dedicated branch named release-X.Y, example: release-0.1.

Testing changes

To run included tests and check code style with golint run:

make test

Vendoring dependencies

If you use any new dependency or remove any existing one, please run:

make vendor

This will install and run dep, which will detect all used package and fetch them into the vendor directory.

To update all vendor package run:

make vendor-update

To update specific vendor package run dep manually:

dep ensure <import-path-filter>

See dep documentation for details.

Javascript & CSS assets

UI is written using React, follow user guide for create-react-app to make changes to the UI code.

Running

To build and start karma from local branch see Running section of the README file.

When working with assets (templates, stylesheets and javascript files) DEBUG make variable can be set, which will recompile binary assets in debug mode, meaning that files from disk will be read instead of compiled in assets. See go-bindata docs for details. Example:

make DEBUG=true run
make DEBUG=true run-docker

Note that this is not the same as enabling debug mode for the gin web framework which is used internally, but enabling DEBUG via this make variable will also enable gin debug mode. When running docker image via make run-docker with DEBUG make variable set to true volume mapping will be added (in read-only mode), so that karma instance running inside the docker can read asset files from the sources directory.

Adding support for new Alertmanager release

To support a new release that breaks API following changes needs to be done:

  • Verify that GetVersion() function can still correctly read remote Alertmanager version via /api/v1/status endpoint, adapt it if needed.
  • Create a new mapper package implementing unmarshaling of alerts and/or silences (depending if both need a new code) under mapper/vXY (X major Alertmanager version, Y minor version).
  • Register new mapper in the init() function in the internal/alertmanager/mapper.go file.