- Contributing to the Dynatrace Configuration as Code Core Libraries
Dynatrace Configuration as Code Core provides libraries simplifying the development of configuration as code tooling for Dynatrace.
It provides Go libraries for things like API clients, which are shared between several Dynatrace configuration as code tools.
The easiest way to start contributing or helping with the Configuration as Code Core 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 libraries are written in Go, so you'll need to have installed Go to build it.
As the libraries provide no executables, you may compile them using make compile, but there are no executables to be built and used.
Generally, make sure to take a look at the Makefile to see available build targets.
Run the unit tests for the whole module with make test in the root folder.
Take a look at Go Testing for more info on testing in Go.
We use github.com/stretchr/testify as a testing/assert library.
Generally, we aim for test coverage above 80% but don't enforce hard limits. Please make sure your code is reasonably well covered by tests.
Go module files go.mod and go.sum are checked-in in the root folder of the repo, so generally, run go from there.
go.mod and go.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!
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.