To get started follow Building from source
section of the README
file.
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
.
To run included tests and check code style with golint
run:
make test
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.
JS and CSS assets are managed via npm and compiled into bundle files using webpack.
To add a new JS asset install it using npm with the --save
flag, this will
add it to the package.json
. Now you can require()
it in javascript code.
JS modules are written using CommonJS
syntax. Webpack will use babel to transform JS code to
ES2015.
During development you can set NODE_ENV=test
before running any make targets,
this will prevent webpack from using expensive optimizations only needed when
generating production assets.
To build and start unsee
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 unsee
instance running inside the docker can read asset files from the sources
directory.
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 theinternal/alertmanager/mapper.go
file.