- Contributing to the Monitoring as Code Tool
This tool was created out of the following needs but not limited to:
- Provide an easy way to deploy numerous Dynatrace monitoring configurations for several applications across different environments such as Development, Pre-production, and Production environments to maintain consistency.
Thus, this tool aims to provide a way to reproducibly deploy Dynatrace monitoring configuration in a "configuration as code"-way.
As with all things Dynatrace, scalability is an important requirement, both in the number of configuration files and the number of environments. This is also the area currently offering the most opportunity to improve the tool.
Another way to contribute is to extend the list of supported APIs. Please take a look at the detailed instructions.
The easiest way to start contributing or helping with the Monitoring as Code project is to pick an existing issue/bug and get to work.
For proposing a change, we seek to discuss potential changes in GitHub issues in advance before implementation. That will allow us to give design feedback up front and set expectations about the scope of the change and, for more significant changes, how best to approach the work such that the Monitoring as Code team can review it and merge it with other concurrent work. This allows being respectful of the time of community contributors.
The repo follows a relatively standard branching & PR workflow.
Branches naming follows the feature/{Issue}/{description} or bugfix/{Issue}/{description} pattern.
Branches are rebased and only fast-forward merges to main permitted. No merge commits.
By default, commits are not auto-squashed when merging a PR, so please ensure your commits are fit to go into main.
For convenience auto-squashing all PR commits into a single one is an optional merge strategy - but we strive for atomic commits with good commit messages in main so not auto-squashing is recommended.
Commits should conform to Conventional Commit standard.
New Feature Changes
feat: allow provided config object to extend other configs
Bug Fix Changes
fix: change function call
see the issue for details
on typos fixed.
Reviewed-by: Z
Refs #133
Documentation Changes
docs: correct getting started guide
More examples can be found here
Before contributing, please read and approve our Code Of Conduct outlining our shared values and expectations.
The monaco tool is written in Go, so you will need to have installed Go to build it.
To build the tool, run make build in the repository root folder.
This guide references the make target for each step. If you want to see the actual Go commands take a look at the Makefile
To install the tool to your machine, run make install in the repository root folder.
This will create a monaco executable you can use.
To build a platform specific executable run: GOOS={OS} GOARCH={ARCH} make build.
For example, a Windows executable can be built with GOOS=windows GOARCH=386 make build BINARY=monaco.exe.
Run the unit tests for the whole module with make test in the root folder.
For convenience single package tests can be run with make test-package pkg={PACKAGE} - e.g. make test-package pkg=api.
In addition to unit tests, the module contains integration tests that upload configuration to two test environments. Those are tagged integration and will be run for any pull request opened for Monitoring as Code.
To run the integration tests, you will need at least one Dynatrace environment - the tests run against two configurable environments.
Define the following environment variables to test for these environments:
URL_ENVIRONMENT_1... URL of the first test environmentTOKEN_ENVIRONMENT_1... API token for the first test environmentURL_ENVIRONMENT_2... URL of the second test environmentTOKEN_ENVIRONMENT_2... API token for the second test environment
Run the integration tests using make integration-test.
Take a look at Go Testing for more info on testing in Go.
Tests should be written in a way that keeps them OS independent, so don't just use / or \for paths!
Instead, whenever you need to test a path, make sure to do it in one of these ways:
- Construct any paths you need using
os.PathSeparator - Use the public function
ReplacePathSeparators, which replaces path separators in a given string withos.PathSeparator
Go module files go.mod and go.sum are checked-in in the root folder of the repo, so generally run go from there.
mod and sum may change while building the project.
To keep those files clean off unnecessary changes, please always run go mod tidy before committing changes to these files!
You can find the source code of the tool in the cmd/monaco and pkg/ folders.
Go Mockgen is used for some generated mock files.
You will have to generate them.
To explicitly generate the mocked files, run make mocks in the root folder.
This project uses the default go formatting tool go fmt.
To format all files, you can use the Make target make format.
Before committing changes, please make sure you've added the pre-commit hook from the hooks folder.
On Unix, you can use the setup-git-hooks.sh to symlink that file into your .git/hooks folder.
Some APIs this tool uses are 'Earlier Adopter' APIs. They may change, and we can't do anything but deal with that when it happens.
If you add a new API please mark it correctly if it should be an 'Early Adopter' API.
If you see that an API has been moved to a final release, please remove the respective comment.