Community Resources

Code Review Guidelines

Here are some of our tips for conducting Code Reviews the SweetOps way. If you haven’t already, become familiar with our Development Best Practices and Terraform Best Practices. Use the “Suggest” feature as much as possible. This makes it quick and easy for the contributor to accept or dismiss the recommendations. Use proper markdown in suggestions (e.g. code blocks) Always be polite and appreciative of the contributions! Use emoticons to up-vote other comments (rather than +1 comments) Use ChatOps commands like /rebuild-readme or /terraform-fmt to fix common problems Use ChatOps commands like /test all, /test bats, /test readme, /test terratest to run integration tests Recommend changes to better conform to our best-practices.

Contributor Tips & Tricks

About This document is intended to describe common and not-so-common processes that the contributor team executes as part of maintaining the 300+ open source projects within the Cloud Posse Organization. Tips & Tricks Update Multiple Repos at Once To update many of the open source repos with a common change such as updating Terraform required_version pinning, adding GitHub actions, or updating pinned providers, the contributor team has adopted using microplane.

GitHub Contributors

About Cloud Posse maintains 300+ projects under our GitHub organization. All of our projects have stemmed from past consulting engagements with our customers. Everything we do is Open Sourced under our GitHub under the permissive APACHE2 license. With so many projects, however, it wouldn’t be possible to maintain all of them if we didn’t have the support from our community and some tools to make life easier. Our Tools Here are some of the tools we depend on for running our Open Source organization.

GitHub Contributors FAQ

How do I see all open Pull Requests? You can find all open Pull Requests by going to GitHub and searching for open PRs. What if we approve and merge a Pull Request with a problem? We encourage everyone who uses our modules to practice version pinning. So while we try to ensure master is always stable, we’re not concerned if we occasionally break things. Also, we believe in a blameless culture.