Contributing to Garden
Last updated
Was this helpful?
Last updated
Was this helpful?
If you love Garden, please ★ star this repository to show your support . Looking for support? Join our Discord.
We heartily welcome any form of contribution to the project, including issue reports, feature requests, discussion, pull requests and any type of feedback. We request that all contributors adhere to the Contributor Covenant and work with us to make the collaboration and community productive and fun for everyone
If you have found a bug, or want to submit a feature request, or suggest any other change, please create a new issue.
If you report a bug, please describe the steps to reproduce it. You can share the complete Garden configuration of your project (without any code included) with us by running the garden get debug-info command. It will produce a single archive that matches the directory structure of your project, but contains only your Garden configuration files. This can be very helpful for us to reproduce and fix the issue.
The project code is composed of several components, most of which are written in TypeScript. There's also a number of supporting scripts, documents, examples etc. Here is an overview of the top-level project folders:
bin
Executable commands, to use for development. Note that you need to build the project before these work.
cli
The Garden CLI package, which composes code from different packages into the final CLI executable.
core
The bulk of the Garden code and tests live here.
docs
examples
Various Garden example projects.
images
Supporting container images, used by e.g. the kubernetes provider.
plugins
Plugins that are bundled with Garden. We are in the process of moving plugins out of core and into separate packages here.
scripts
Various scripts for builds, releases and development.
sdk
The @garden-io/sdk package, used for Garden plugin development.
secrets
Encrypted files, used for integ/e2e testing. Only accessible to Garden maintainers.
static
Static files that are bundled with the CLI.
support
Supporting files for development, builds, releases etc.
We use Prettier for automated formatting. We highly recommend installing the appropriate plugin for your editor to automate formatting as you work on your code. You can also run npm run fix-format to fix formatting across the codebase.
We follow the Conventional Commits specification and automatically validate the formatting of our commit messages. In particular, the type of the commit header must be one of the following:
chore: Changes to the build process or auxiliary tools and libraries such as documentation generation.
ci: Changes to the CI configuration.
docs: Documentation only changes.
feat: A new feature.
fix: A bug fix.
improvement: Changes that improve a current implementation without adding a new feature or fixing a bug.
perf: A code change that improves performance.
refactor: A code change that neither fixes a bug nor adds a feature.
revert: A commit that reverts a previous commit. It should begin with revert:, followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.
style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
test: Adding missing or correcting existing tests.
tool: A version update for a bundled tool version used by Garden.
When generating the changelog, we only include the following types: feat, fix, refactor, improvement, and perf. This means that any changes that the user should be aware of, should have one of these types.
We have scripts for checking licenses, docs, linting and more. These can all be run with a single command:
If the checks fail because of bad formatting, run:
If the checks fail because of missing docs, run:
Before pushing, we automatically run the check-pre-push script (which runs the scripts in check-all, except for check-docs), as well as unit tests. To skip these, run push with the --no-verify flag:
You should set the following environment variables when developing on Garden:
We use Circle CI for integration and end-to-end testing. The configuration is in .circleci/config.yml.
Every source file must include the contents of support/license-header.txt at the top. This is automatically checked during CI. Since it's defined as an eslint rule, you can run the check with npm run lint.
Our release process generates the following packages:
An executable for OSX, Linux, and Windows hosted on our Github page.
A Homebrew package for OSX users.
Check out our release process guide for more details.
We keep a changelog under CHANGELOG.md that gets updated on every release. For pre-releases, we include every pre-release tag in that release cycle in the changelog. So if we're releasing, say, 0.12.6-3, the changelog will include entries for 0.12.6-0, 0.12.6-1, 0.12.6-2, assuming those tags exist. Once we make a proper release, we remove the pre-release tags so that the changelog only shows changes between 0.12.5 and 0.12.6. A changelog with the pre-releases is of course always available in our Git history.
Markdown documentation, which is used to generate . Note that the reference docs are auto-generated, and should not be edited by hand!.