- Contributing to the Configuration as Code Tool Monaco
- What to contribute
- How to contribute
- Examples of Commit Style Messages
- Code of Conduct and Shared Values
- Building the Dynatrace Configuration as Code Tool
- Testing the Dynatrace Configuration as Code Tool
- Checking in go mod and sum files
- General information on code
- Pre-Commit Hook
- A note on Dynatrace APIs
This tool was created out of the following needs but not limited to:
- Provide an easy way to deploy numerous Dynatrace 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 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.
The easiest way to start contributing or helping with the Configuration as Code project is to pick an existing issue/bug and get to work.
For proposing a change, we'd like to discuss potential changes in GitHub issues 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 Configuration 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 are 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'll 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'll 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
We use github.com/stretchr/testify as our testing library.
You might still find
gotest.toolsused for asserts in a few places, as it's being replaced. If you change a test file using it, replace it.
We use require for asserting test requirements after which it makes no sense to continue - e.g. no error was returned, a slice has the expected length, pointers aren't nil, etc. - as it will fail the test immediately and exit.
We use assert for asserting results after which we still want to know about more results - e.g. checking the values of several struct fields, checking the complete contents of a slice, etc.
If in doubt, use require to avoid follow-on errors and panics if data was already invalid.
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 of 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'll 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.