We love your input and welcome community inclusion wherever possible.
We want to make contributing to the community and projects as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
We use Github to host code, to track issues and feature requests, as well as accept pull requests.
Pull requests are the best way to propose changes to the codebase (we use Github Flow). We actively welcome your pull requests
The example workflow for Terraform submissions is as follows, but is applicable for other pieces of code generally:
- Fork the repo and create your branch from
main
. - Ensure you have tested your code with
terraform validate
,tfsec
andcheckov
or other linting and security tools. - Format your terraform using
terraform fmt -recursive
or another code formtter, such as prettier - Module files and variable should use a "What you see is what you get" naming convention (WYSIWYG), so for example:
terraform-${provider}-${purpose}/ # Provider may be azurerm for example, and provider might be virtual-network for example
|
├── ${purpose}.tf # For the main terraform function of the terraform code, e.g. a virtual network, so should be called vnet.tf
├── input.tf # For input variables
├── LICENSE # MIT License only
├── locals.tf # For locals if needed
├── output.tf # For output variables
├── README.md # README documentation
- All
README.md
files should be contain content. For Terraform, it should always have an example code block of a successful execution of the module, followed by a terraform-docs output, using the markdown format, for example:
terraform-docs markdown . >> README.md
- All variables should be placed in alphabetical order. For terraform, this can be done using the the util script:
curl https://raw.githubusercontent.com/libre-devops/utils/dev/scripts/terraform/tf-sort.sh | bash
- Issue that pull request!
In short, when you submit code changes, your submissions are understood to be under the same MIT License that covers the project. Feel free to contact the maintainers if that's a concern.
Report bugs using Github's issues
We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!
Great Bug Reports tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give sample code if you can.
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
People love thorough bug reports. I'm not even kidding.
By contributing, you agree that your contributions will be licensed under its MIT License.