Thanks for contributing to Terrabuild and helping make it better. We appreciate the help!
You are welcome to join the Terrabuild Community Slack for questions and feature requests. We discuss features and file bugs on GitHub via Issues.
Please keep in mind Terrabuild is a young product. We are doing our best to move forward while keeping product simple.
For larger features, we'd appreciate it if you open a new issue before investing a lot of time so we can discuss the feature together. Please also be sure to browse current issues to make sure your issue is unique, to lighten the triage burden on our maintainers. Finally, please limit your pull requests to contain only one feature at a time. Separating feature work into individual pull requests helps speed up code review and reduces the barrier to merge.
You'll want to install the following on your machine:
We use make as shortcuts to run commands.
We develop mainly on macOS and Ubuntu, with limited support for doing development on Windows. Feel free to pitch in if you can help improve that.
Makefile contains several targets. The most useful day-to-day targets are:
build: build Terrabuild. This is the default target.parser: rebuild parser and start build.test: build and run tests.publish: build and publish.self: publish and run Terrabuild against itself (build test dist).smoke-tests: run integration scenarios undertests/and compare debug output snapshots.try-docs: run DocGen in dry-run mode and validate extension docs metadata parsing.terrabuild: runbuild test distusing the globally installed Terrabuild.
You probably also want to install current Terrabuild distribution: dotnet tool install --global terrabuild
Use dotnet tool install --global --prerelease terrabuild if you want pre-release version instead.
For extension/script protocol changes:
make try-docsmake testmake smoke-testsmake self
For broad/core runtime changes:
make testmake selfmake smoke-testsmake try-docs
If make smoke-tests produces diffs in tests/*/results, investigate and explain the root cause before merging.
For contributors we use the standard GitHub workflow: fork, create a branch and when ready, open a pull request from your fork.
Changelog notes are written in the active imperative form. They should not end with a period. The simple rule is to pretend the message starts with "This change will ..."
Good examples for changelog entries are:
- move whatif at task level
- invalidate local cache on cache inconsistency
Here's some examples of what we're trying to avoid:
- Fixes a bug
- Adds a feature
- Feature now does something
Magnus Opera employees have write access to Magnus Opera repositories and must push directly to branches rather than forking the repository. Tests can run directly without approval for PRs based on branches rather than forks.
Terrabuild uses a draft-based release flow:
- Run
make release-prepare version=X.Y.Z(stable) ormake release-prepare version=X.Y.Z-next(preview). - Push commit and tag with
git push origin main --follow-tags. - Wait for CI to create a draft GitHub release and upload artifacts.
- Publish that existing draft release.
make release-prepare supports X.Y.Z and X.Y.Z-next only. Use dryrun=true to validate release preparation without writing changes.
We're sure there are rough edges and we appreciate you helping out. If you want to talk with other folks in the Terrabuild community (including members of the Magnus Opera team) come hang out in the #contribute channel on the Terrabuild Community Slack.