From 2b8b67b2bc18ab09eefcaab99c17221abaa1c382 Mon Sep 17 00:00:00 2001 From: Eugene K Date: Tue, 25 Jan 2022 16:24:50 -0500 Subject: [PATCH 1/3] Add Contributing and Forking sections This PR adds two new sections to the Guides area: - Contributing - Forking These new pages will live under a new "working-with-our-code" area. Additionally we're moving the "versioning" guide from "stay-up-to-date" to "working-with-our-code". --- ...runtwork-infrastructure-as-code-library.md | 4 +- ...runtwork-infrastructure-as-code-library.md | 4 +- .../deployment-walkthrough.md | 4 +- ...runtwork-infrastructure-as-code-library.md | 4 +- ...runtwork-infrastructure-as-code-library.md | 4 +- ...runtwork-infrastructure-as-code-library.md | 4 +- ...runtwork-infrastructure-as-code-library.md | 4 +- .../guides/working-with-code/contributing.md | 51 ++++++++++++++++ .../guides/working-with-code/forking.md | 56 +++++++++++++++++ .../versioning.md} | 0 ...runtwork-infrastructure-as-code-library.md | 6 +- ...runtwork-infrastructure-as-code-library.md | 6 +- .../deployment-walkthrough.md | 6 +- ...runtwork-infrastructure-as-code-library.md | 6 +- ...runtwork-infrastructure-as-code-library.md | 6 +- ...runtwork-infrastructure-as-code-library.md | 6 +- ...runtwork-infrastructure-as-code-library.md | 6 +- docs/guides/working-with-code/contributing.md | 56 +++++++++++++++++ docs/guides/working-with-code/forking.md | 61 +++++++++++++++++++ .../versioning.md} | 0 sidebars/guides-index.js | 9 +++ 21 files changed, 268 insertions(+), 35 deletions(-) create mode 100644 _docs-sources/guides/working-with-code/contributing.md create mode 100644 _docs-sources/guides/working-with-code/forking.md rename _docs-sources/guides/{stay-up-to-date/01-versioning.md => working-with-code/versioning.md} (100%) create mode 100644 docs/guides/working-with-code/contributing.md create mode 100644 docs/guides/working-with-code/forking.md rename docs/guides/{stay-up-to-date/01-versioning.md => working-with-code/versioning.md} (100%) diff --git a/_docs-sources/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/_docs-sources/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md index b9b713e46d..87f0b49936 100644 --- a/_docs-sources/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/_docs-sources/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -18,7 +18,7 @@ To update to the CIS AWS Foundations Benchmark v1.3.0, you need to update your r Infrastructure as Code Library to use compatible versions. We (Gruntwork) have reviewed and updated all the library modules for compatibility with the new version of the Benchmark. As a customer, you need to update to the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to [the -"Updating to new versions" section of "Stay Up to Date"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) for instructions on how to update the +"Updating to new versions" section of "Stay Up to Date"](/docs/guides/working-with-code/versioning#updating-to-new-versions) for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos @@ -30,7 +30,7 @@ version.** Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward incompatible releases for any version updates before the 1.0.0 release. Make sure to read the release notes for the relevant modules any time you are updating minor versions! Note that you will want to read the release notes for each minor version that is updated (e.g., if you are going from v0.5.x to v0.9.x, you will want to read the notes for v0.6.0, diff --git a/_docs-sources/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/_docs-sources/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md index adcecb328e..ccde6a6da0 100644 --- a/_docs-sources/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/_docs-sources/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -7,12 +7,12 @@ sidebar_label: Update references to the Gruntwork Infrastructure as Code Library To update to the CIS AWS Foundations Benchmark v1.4.0, you need to update your references to the Gruntwork Infrastructure as Code Library to use compatible versions. We (Gruntwork) have reviewed and updated all the library modules for compatibility with the new version of the benchmark. As a customer, you need to update to -the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the +the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward incompatible releases for any version updates before the 1.0.0 release. Make sure to read the release notes for the relevant modules any time you are updating minor versions! Note that you will want to read the release notes for each minor version that is updated (e.g., if you are going from v0.5.x to v0.9.x, you will want to read the notes for v0.6.0, diff --git a/_docs-sources/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md b/_docs-sources/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md index 5df6306702..ceb759bf97 100644 --- a/_docs-sources/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md +++ b/_docs-sources/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md @@ -8,7 +8,7 @@ library to test and update the code to be compatible with AWS provider version 3 the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Be sure to read the release notes to know what changes need to be made to update to that version. -Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide +Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. The following table provides a summary of all the relevant Gruntwork AWS modules and the respective versions that are @@ -17,7 +17,7 @@ compatible with AWS provider version 3. :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any diff --git a/_docs-sources/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/_docs-sources/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md index b3dbad4084..38c84b787f 100644 --- a/_docs-sources/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/_docs-sources/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -10,7 +10,7 @@ version. We (Gruntwork) have gone through all our modules in the library to test and update the code to be compatible with Terraform 1.x. As a customer, you need to update to the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to [the "Updating to new versions" section of -"Stay Up to Date"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions#updating) +"Stay Up to Date"](/docs/guides/working-with-code/versioning#updating-to-new-versions#updating) for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a @@ -22,7 +22,7 @@ changes need to be made to update to the new version.** :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any diff --git a/_docs-sources/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/_docs-sources/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md index 82d78d134e..1f6ed58d7b 100644 --- a/_docs-sources/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/_docs-sources/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references In order to take advantage of the Terraform 0.13, you need to update your references to the Gruntwork Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the library to test and update the code to be compatible with Terraform 0.13. As a customer, you need to update to -the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the +the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos @@ -19,7 +19,7 @@ user, pay special attention to the release notes! :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any diff --git a/_docs-sources/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/_docs-sources/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md index 09687f23eb..109c85c5a2 100644 --- a/_docs-sources/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/_docs-sources/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references In order to take advantage of the Terraform 0.14, you need to update your references to the Gruntwork Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the library to test and update the code to be compatible with Terraform 0.14. As a customer, you need to update to -the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the +the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos @@ -18,7 +18,7 @@ version.** :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any diff --git a/_docs-sources/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/_docs-sources/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md index a795d1bc76..0e8c673f89 100644 --- a/_docs-sources/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/_docs-sources/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references In order to take advantage of the Terraform 0.15, you need to update your references to the Gruntwork Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the library to test and update the code to be compatible with Terraform 0.15. As a customer, you need to update to -the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the +the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos @@ -18,7 +18,7 @@ version.** :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any diff --git a/_docs-sources/guides/working-with-code/contributing.md b/_docs-sources/guides/working-with-code/contributing.md new file mode 100644 index 0000000000..f833db8894 --- /dev/null +++ b/_docs-sources/guides/working-with-code/contributing.md @@ -0,0 +1,51 @@ +--- +sidebar_label: "Contributing code" +--- + +# Contributing to the Gruntwork Infrastructure as Code Library + +Contributions to the Gruntwork Infrastructure as Code Library are very welcome and appreciated! If you find a bug or want to add a new +feature or even contribute an entirely new module, we are very happy to accept +[pull requests](https://help.github.com/articles/about-pull-requests/), provide feedback, and run your changes through +our automated test suite. + +This section outlines the process for contributing. + +## File a GitHub issue + +Before starting any work, we recommend filing a GitHub issue in the appropriate repo. This is your chance to ask +questions and get feedback from the maintainers and the community before you sink a lot of time into writing (possibly +the wrong) code. If there is anything you’re unsure about, just ask! + +## Update the documentation + +We recommend updating the documentation _before_ updating any code (see +[Readme Driven Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)). This ensures the +documentation stays up to date and allows you to think through the problem at a high level before you get lost in the +weeds of coding. + +## Update the tests + +We also recommend updating the automated tests _before_ updating any code (see +[Test Driven Development](https://en.wikipedia.org/wiki/Test-driven_development)). That means you add or update a test +case, verify that it’s failing with a clear error message, and then make the code changes to get that test to pass. +This ensures the tests stay up to date and verify all the functionality in the repo, including whatever new +functionality you’re adding in your contribution. The `test` folder in every repo will have documentation on how to run +the tests locally. + +## Update the code + +At this point, make your code changes and use your new test case to verify that everything is working. + +## Create a pull request + +[Create a pull request](https://help.github.com/articles/creating-a-pull-request/) with your changes. Please make sure +to include the following: + +1. A description of the change, including a link to your GitHub issue. +2. Any notes on backwards incompatibility. + +## Merge and release + +The maintainers for the repo will review your code and provide feedback. If everything looks good, they will merge the +code and release a new version. diff --git a/_docs-sources/guides/working-with-code/forking.md b/_docs-sources/guides/working-with-code/forking.md new file mode 100644 index 0000000000..be229fe09d --- /dev/null +++ b/_docs-sources/guides/working-with-code/forking.md @@ -0,0 +1,56 @@ +--- +sidebar_label: "Forking our code" +--- + +# Forking the Gruntwork Infrastructure as Code Library + +The [Gruntwork Terms of Service](https://gruntwork.io/terms/) give you permissions to fork the code from the Gruntwork +Infrastructure as Code Library into your own repos. This is useful if your company does not allow external dependencies (e.g., you +have a company policy that requires all source code to be pulled from an internal GitHub Enterprise or BitBucket +server) or if you need to make modifications to the Infrastructure as Code Library that you do not wish to contribute back to +Gruntwork. This section will walk you through what you need to do to fork the code. + +The definition of an _Authorized User_ from the Gruntwork Terms of Service does NOT change if you fork the +code. That is, if you create internal forks and give 50 users access to those internal forks, then the Gruntwork +License requires that you pay for 50 Authorized Users. + +## How to fork the code + +Here is how you fork the code in the Gruntwork Infrastructure as Code Library: + +1. Copy each Gruntwork repo into your private repositories. +2. You’ll also want to copy all the versioned releases (see the `/releases` page for each repo). +3. For repos that contain pre-built binaries (such as `ssh-grunt` mentioned earlier), you’ll want to copy those binaries + as well. +4. Within each repo, search for any cross-references to other Gruntwork repos. Most of the repos are standalone, but + some of the Terraform and Go code is shared across repos (e.g., the `package-kafka` and `package-zookeeper` repos + use the `module-asg` repo under the hood to run an Auto Scaling Group). You’ll need to update Terraform source URLs + and Go import statements from `github.com/gruntwork-io` to your private Git repo URLs. + +You’ll want to automate the entire process above and run it on a regular schedule (e.g., daily). The Gruntwork +Infrastructure as Code Library is updated continuously, both by the Gruntwork team and contributions from our community +of customers (see the monthly [Gruntwork Newsletter](https://blog.gruntwork.io/tagged/gruntwork-newsletter) for details), +so you’ll want to pull in these updates as quickly as you can. + +## How to use your forked code + +Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](#using_terraform_modules) and +[Using scripts and binaries](#using_scripts_binaries), except for the following differences: + +1. Point the `source` URLs of your Terraform modules to your own Git repos, rather than the `gruntwork-io` GitHub org. +2. Point the `--repo` parameter of `gruntwork-install` to your own Git repos, rather than the `gruntwork-io` GitHub org. + +## Drawbacks to forking + +While forking is allowed under the Gruntwork Terms of Services, it has some downsides: + +- You have to do a lot of work up-front to copy the repos, releases, and pre-compiled binaries and update internal + links. +- You have to do more work to run this process on a regular basis and deal with merge conflicts. +- If your team isn’t directly using the Gruntwork GitHub repos on a regular basis, then you’re less likely to + participate in issues and pull requests, and you won’t be benefiting as much from the Gruntwork community. + +So, whenever possible, use the code directly from the `gruntwork-io` GitHub org, as documented in +[Using Terraform Modules](#using_terraform_modules) and [Using scripts and binaries](#using_scripts_binaries). If your team relies on NPM, Docker Hub, Maven Central, +GitHub, or the Terraform Registry, using Gruntwork repos directly is no different. However, if your company completely +bans all outside sources, then follow the instructions above to fork the code, and good luck! diff --git a/_docs-sources/guides/stay-up-to-date/01-versioning.md b/_docs-sources/guides/working-with-code/versioning.md similarity index 100% rename from _docs-sources/guides/stay-up-to-date/01-versioning.md rename to _docs-sources/guides/working-with-code/versioning.md diff --git a/docs/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/docs/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md index f85cf92e97..25f3c67691 100644 --- a/docs/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/docs/guides/stay-up-to-date/cis/cis-1.3.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -18,7 +18,7 @@ To update to the CIS AWS Foundations Benchmark v1.3.0, you need to update your r Infrastructure as Code Library to use compatible versions. We (Gruntwork) have reviewed and updated all the library modules for compatibility with the new version of the Benchmark. As a customer, you need to update to the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to [the -"Updating to new versions" section of "Stay Up to Date"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) for instructions on how to update the +"Updating to new versions" section of "Stay Up to Date"](/docs/guides/working-with-code/versioning#updating-to-new-versions) for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos @@ -30,7 +30,7 @@ version.** Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward incompatible releases for any version updates before the 1.0.0 release. Make sure to read the release notes for the relevant modules any time you are updating minor versions! Note that you will want to read the release notes for each minor version that is updated (e.g., if you are going from v0.5.x to v0.9.x, you will want to read the notes for v0.6.0, @@ -187,5 +187,5 @@ compatible with CIS AWS v1.3.0: diff --git a/docs/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/docs/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md index 2682e15624..54cc2d206f 100644 --- a/docs/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/docs/guides/stay-up-to-date/cis/cis-1.4.0/deployment-walkthrough/step-1-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -7,12 +7,12 @@ sidebar_label: Update references to the Gruntwork Infrastructure as Code Library To update to the CIS AWS Foundations Benchmark v1.4.0, you need to update your references to the Gruntwork Infrastructure as Code Library to use compatible versions. We (Gruntwork) have reviewed and updated all the library modules for compatibility with the new version of the benchmark. As a customer, you need to update to -the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the +the proper versions of the Gruntwork library to pick up the fixes/changes made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backward incompatible releases for any version updates before the 1.0.0 release. Make sure to read the release notes for the relevant modules any time you are updating minor versions! Note that you will want to read the release notes for each minor version that is updated (e.g., if you are going from v0.5.x to v0.9.x, you will want to read the notes for v0.6.0, @@ -82,5 +82,5 @@ compatible with CIS AWS v1.4.0: diff --git a/docs/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md b/docs/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md index 93fa27f996..c42e7b6c3e 100644 --- a/docs/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md +++ b/docs/guides/stay-up-to-date/terraform/how-to-update-to-aws-provider-v3/deployment-walkthrough.md @@ -8,7 +8,7 @@ library to test and update the code to be compatible with AWS provider version 3 the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Be sure to read the release notes to know what changes need to be made to update to that version. -Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide +Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. The following table provides a summary of all the relevant Gruntwork AWS modules and the respective versions that are @@ -17,7 +17,7 @@ compatible with AWS provider version 3. :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any @@ -182,5 +182,5 @@ on how to update your components to be compatible with AWS provider v3. diff --git a/docs/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/docs/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md index ca29beca00..d92cc93a1f 100644 --- a/docs/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/docs/guides/stay-up-to-date/terraform/terraform-1.x/deployment-walkthrough/step-2-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -10,7 +10,7 @@ version. We (Gruntwork) have gone through all our modules in the library to test and update the code to be compatible with Terraform 1.x. As a customer, you need to update to the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to [the "Updating to new versions" section of -"Stay Up to Date"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions#updating) +"Stay Up to Date"](/docs/guides/working-with-code/versioning#updating-to-new-versions#updating) for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a @@ -22,7 +22,7 @@ changes need to be made to update to the new version.** :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any @@ -174,5 +174,5 @@ and the respective versions that are compatible with Terraform 1.x: diff --git a/docs/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/docs/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md index fa8c59a77a..c5d07e9354 100644 --- a/docs/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/docs/guides/stay-up-to-date/terraform/terraform-13/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references In order to take advantage of the Terraform 0.13, you need to update your references to the Gruntwork Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the library to test and update the code to be compatible with Terraform 0.13. As a customer, you need to update to -the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the +the proper versions of the Gruntwork library to pick up the fixes/changes that were made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos @@ -19,7 +19,7 @@ user, pay special attention to the release notes! :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any @@ -171,5 +171,5 @@ compatible with Terraform 0.13: diff --git a/docs/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/docs/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md index e2e912f623..98165e10be 100644 --- a/docs/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/docs/guides/stay-up-to-date/terraform/terraform-14/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references In order to take advantage of the Terraform 0.14, you need to update your references to the Gruntwork Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the library to test and update the code to be compatible with Terraform 0.14. As a customer, you need to update to -the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the +the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos @@ -18,7 +18,7 @@ version.** :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any @@ -170,5 +170,5 @@ compatible with Terraform 0.14: diff --git a/docs/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md b/docs/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md index 36bc8e54ef..19a1edc7d5 100644 --- a/docs/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md +++ b/docs/guides/stay-up-to-date/terraform/terraform-15/deployment-walkthrough/step-3-update-references-to-the-gruntwork-infrastructure-as-code-library.md @@ -7,7 +7,7 @@ sidebar_label: Update Gruntwork IaC module references In order to take advantage of the Terraform 0.15, you need to update your references to the Gruntwork Infrastructure as Code Library to use a compatible version. We (Gruntwork) have gone through all our modules in the library to test and update the code to be compatible with Terraform 0.15. As a customer, you need to update to -the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/stay-up-to-date/versioning#updating-to-new-versions) guide for instructions on how to update the +the proper versions of the Gruntwork library to pick up the fixes/changes that we made to be compatible. Refer to our ["Updating to new versions"](/docs/guides/working-with-code/versioning#updating-to-new-versions) guide for instructions on how to update the versions in your code. For the vast majority of the repos, the only change that will be necessary is a version number bump, but several repos @@ -18,7 +18,7 @@ version.** :::caution Gruntwork follows [semantic -versioning](/docs/guides/stay-up-to-date/versioning#semantic-versioning). +versioning](/docs/guides/working-with-code/versioning#semantic-versioning). For any pre-1.0 modules, this means that version updates to the minor version are considered backwards incompatible releases for any version updates prior to 1.0.0 release. Make sure to read the release notes for the relevant modules any @@ -170,5 +170,5 @@ compatible with Terraform 0.15: diff --git a/docs/guides/working-with-code/contributing.md b/docs/guides/working-with-code/contributing.md new file mode 100644 index 0000000000..ec91c2ac0f --- /dev/null +++ b/docs/guides/working-with-code/contributing.md @@ -0,0 +1,56 @@ +--- +sidebar_label: "Contributing code" +--- + +# Contributing to the Gruntwork Infrastructure as Code Library + +Contributions to the Gruntwork Infrastructure as Code Library are very welcome and appreciated! If you find a bug or want to add a new +feature or even contribute an entirely new module, we are very happy to accept +[pull requests](https://help.github.com/articles/about-pull-requests/), provide feedback, and run your changes through +our automated test suite. + +This section outlines the process for contributing. + +## File a GitHub issue + +Before starting any work, we recommend filing a GitHub issue in the appropriate repo. This is your chance to ask +questions and get feedback from the maintainers and the community before you sink a lot of time into writing (possibly +the wrong) code. If there is anything you’re unsure about, just ask! + +## Update the documentation + +We recommend updating the documentation _before_ updating any code (see +[Readme Driven Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html)). This ensures the +documentation stays up to date and allows you to think through the problem at a high level before you get lost in the +weeds of coding. + +## Update the tests + +We also recommend updating the automated tests _before_ updating any code (see +[Test Driven Development](https://en.wikipedia.org/wiki/Test-driven_development)). That means you add or update a test +case, verify that it’s failing with a clear error message, and then make the code changes to get that test to pass. +This ensures the tests stay up to date and verify all the functionality in the repo, including whatever new +functionality you’re adding in your contribution. The `test` folder in every repo will have documentation on how to run +the tests locally. + +## Update the code + +At this point, make your code changes and use your new test case to verify that everything is working. + +## Create a pull request + +[Create a pull request](https://help.github.com/articles/creating-a-pull-request/) with your changes. Please make sure +to include the following: + +1. A description of the change, including a link to your GitHub issue. +2. Any notes on backwards incompatibility. + +## Merge and release + +The maintainers for the repo will review your code and provide feedback. If everything looks good, they will merge the +code and release a new version. + + + diff --git a/docs/guides/working-with-code/forking.md b/docs/guides/working-with-code/forking.md new file mode 100644 index 0000000000..1347768718 --- /dev/null +++ b/docs/guides/working-with-code/forking.md @@ -0,0 +1,61 @@ +--- +sidebar_label: "Forking our code" +--- + +# Forking the Gruntwork Infrastructure as Code Library + +The [Gruntwork Terms of Service](https://gruntwork.io/terms/) give you permissions to fork the code from the Gruntwork +Infrastructure as Code Library into your own repos. This is useful if your company does not allow external dependencies (e.g., you +have a company policy that requires all source code to be pulled from an internal GitHub Enterprise or BitBucket +server) or if you need to make modifications to the Infrastructure as Code Library that you do not wish to contribute back to +Gruntwork. This section will walk you through what you need to do to fork the code. + +The definition of an _Authorized User_ from the Gruntwork Terms of Service does NOT change if you fork the +code. That is, if you create internal forks and give 50 users access to those internal forks, then the Gruntwork +License requires that you pay for 50 Authorized Users. + +## How to fork the code + +Here is how you fork the code in the Gruntwork Infrastructure as Code Library: + +1. Copy each Gruntwork repo into your private repositories. +2. You’ll also want to copy all the versioned releases (see the `/releases` page for each repo). +3. For repos that contain pre-built binaries (such as `ssh-grunt` mentioned earlier), you’ll want to copy those binaries + as well. +4. Within each repo, search for any cross-references to other Gruntwork repos. Most of the repos are standalone, but + some of the Terraform and Go code is shared across repos (e.g., the `package-kafka` and `package-zookeeper` repos + use the `module-asg` repo under the hood to run an Auto Scaling Group). You’ll need to update Terraform source URLs + and Go import statements from `github.com/gruntwork-io` to your private Git repo URLs. + +You’ll want to automate the entire process above and run it on a regular schedule (e.g., daily). The Gruntwork +Infrastructure as Code Library is updated continuously, both by the Gruntwork team and contributions from our community +of customers (see the monthly [Gruntwork Newsletter](https://blog.gruntwork.io/tagged/gruntwork-newsletter) for details), +so you’ll want to pull in these updates as quickly as you can. + +## How to use your forked code + +Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](#using_terraform_modules) and +[Using scripts and binaries](#using_scripts_binaries), except for the following differences: + +1. Point the `source` URLs of your Terraform modules to your own Git repos, rather than the `gruntwork-io` GitHub org. +2. Point the `--repo` parameter of `gruntwork-install` to your own Git repos, rather than the `gruntwork-io` GitHub org. + +## Drawbacks to forking + +While forking is allowed under the Gruntwork Terms of Services, it has some downsides: + +- You have to do a lot of work up-front to copy the repos, releases, and pre-compiled binaries and update internal + links. +- You have to do more work to run this process on a regular basis and deal with merge conflicts. +- If your team isn’t directly using the Gruntwork GitHub repos on a regular basis, then you’re less likely to + participate in issues and pull requests, and you won’t be benefiting as much from the Gruntwork community. + +So, whenever possible, use the code directly from the `gruntwork-io` GitHub org, as documented in +[Using Terraform Modules](#using_terraform_modules) and [Using scripts and binaries](#using_scripts_binaries). If your team relies on NPM, Docker Hub, Maven Central, +GitHub, or the Terraform Registry, using Gruntwork repos directly is no different. However, if your company completely +bans all outside sources, then follow the instructions above to fork the code, and good luck! + + + diff --git a/docs/guides/stay-up-to-date/01-versioning.md b/docs/guides/working-with-code/versioning.md similarity index 100% rename from docs/guides/stay-up-to-date/01-versioning.md rename to docs/guides/working-with-code/versioning.md diff --git a/sidebars/guides-index.js b/sidebars/guides-index.js index ff6fd02c6d..8dee6824cd 100644 --- a/sidebars/guides-index.js +++ b/sidebars/guides-index.js @@ -24,6 +24,15 @@ const guidesIndex = [ type: "doc", id: "guides/style/index", }, + { + label: "Working with our code", + type: "category", + items: [ + "guides/working-with-code/versioning", + "guides/working-with-code/contributing", + "guides/working-with-code/forking", + ], + }, ] module.exports = guidesIndex From cfc5941d43deab77041de929928804a9b3e2a227 Mon Sep 17 00:00:00 2001 From: Eugene K Date: Wed, 26 Jan 2022 15:20:37 -0500 Subject: [PATCH 2/3] Fixed a few broken anchor links but LEFT one instance of broken links. We are tracking these in JIRA https://gruntwork.atlassian.net/browse/APT-1647 --- _docs-sources/guides/working-with-code/forking.md | 4 ++-- docs/guides/working-with-code/forking.md | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/_docs-sources/guides/working-with-code/forking.md b/_docs-sources/guides/working-with-code/forking.md index be229fe09d..e9a13b21a5 100644 --- a/_docs-sources/guides/working-with-code/forking.md +++ b/_docs-sources/guides/working-with-code/forking.md @@ -34,7 +34,7 @@ so you’ll want to pull in these updates as quickly as you can. ## How to use your forked code -Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](#using_terraform_modules) and +Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules) and [Using scripts and binaries](#using_scripts_binaries), except for the following differences: 1. Point the `source` URLs of your Terraform modules to your own Git repos, rather than the `gruntwork-io` GitHub org. @@ -51,6 +51,6 @@ While forking is allowed under the Gruntwork Terms of Services, it has some down participate in issues and pull requests, and you won’t be benefiting as much from the Gruntwork community. So, whenever possible, use the code directly from the `gruntwork-io` GitHub org, as documented in -[Using Terraform Modules](#using_terraform_modules) and [Using scripts and binaries](#using_scripts_binaries). If your team relies on NPM, Docker Hub, Maven Central, +[Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules) and [Using scripts and binaries](#using_scripts_binaries). If your team relies on NPM, Docker Hub, Maven Central, GitHub, or the Terraform Registry, using Gruntwork repos directly is no different. However, if your company completely bans all outside sources, then follow the instructions above to fork the code, and good luck! diff --git a/docs/guides/working-with-code/forking.md b/docs/guides/working-with-code/forking.md index 1347768718..6f2d85227e 100644 --- a/docs/guides/working-with-code/forking.md +++ b/docs/guides/working-with-code/forking.md @@ -34,7 +34,7 @@ so you’ll want to pull in these updates as quickly as you can. ## How to use your forked code -Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](#using_terraform_modules) and +Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules) and [Using scripts and binaries](#using_scripts_binaries), except for the following differences: 1. Point the `source` URLs of your Terraform modules to your own Git repos, rather than the `gruntwork-io` GitHub org. @@ -51,11 +51,11 @@ While forking is allowed under the Gruntwork Terms of Services, it has some down participate in issues and pull requests, and you won’t be benefiting as much from the Gruntwork community. So, whenever possible, use the code directly from the `gruntwork-io` GitHub org, as documented in -[Using Terraform Modules](#using_terraform_modules) and [Using scripts and binaries](#using_scripts_binaries). If your team relies on NPM, Docker Hub, Maven Central, +[Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules) and [Using scripts and binaries](#using_scripts_binaries). If your team relies on NPM, Docker Hub, Maven Central, GitHub, or the Terraform Registry, using Gruntwork repos directly is no different. However, if your company completely bans all outside sources, then follow the instructions above to fork the code, and good luck! From a98c006ba6a8d1411659c604309c368d5f8ea68d Mon Sep 17 00:00:00 2001 From: Eugene K Date: Wed, 26 Jan 2022 16:09:48 -0500 Subject: [PATCH 3/3] Removed broken link - I updated the JIRA to reference the old sentences. --- _docs-sources/guides/working-with-code/forking.md | 5 ++--- docs/guides/working-with-code/forking.md | 7 +++---- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/_docs-sources/guides/working-with-code/forking.md b/_docs-sources/guides/working-with-code/forking.md index e9a13b21a5..d1fe3be9fa 100644 --- a/_docs-sources/guides/working-with-code/forking.md +++ b/_docs-sources/guides/working-with-code/forking.md @@ -34,8 +34,7 @@ so you’ll want to pull in these updates as quickly as you can. ## How to use your forked code -Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules) and -[Using scripts and binaries](#using_scripts_binaries), except for the following differences: +Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules), except for the following differences: 1. Point the `source` URLs of your Terraform modules to your own Git repos, rather than the `gruntwork-io` GitHub org. 2. Point the `--repo` parameter of `gruntwork-install` to your own Git repos, rather than the `gruntwork-io` GitHub org. @@ -51,6 +50,6 @@ While forking is allowed under the Gruntwork Terms of Services, it has some down participate in issues and pull requests, and you won’t be benefiting as much from the Gruntwork community. So, whenever possible, use the code directly from the `gruntwork-io` GitHub org, as documented in -[Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules) and [Using scripts and binaries](#using_scripts_binaries). If your team relies on NPM, Docker Hub, Maven Central, +[Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules). If your team relies on NPM, Docker Hub, Maven Central, GitHub, or the Terraform Registry, using Gruntwork repos directly is no different. However, if your company completely bans all outside sources, then follow the instructions above to fork the code, and good luck! diff --git a/docs/guides/working-with-code/forking.md b/docs/guides/working-with-code/forking.md index 6f2d85227e..09ea9501cb 100644 --- a/docs/guides/working-with-code/forking.md +++ b/docs/guides/working-with-code/forking.md @@ -34,8 +34,7 @@ so you’ll want to pull in these updates as quickly as you can. ## How to use your forked code -Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules) and -[Using scripts and binaries](#using_scripts_binaries), except for the following differences: +Once you’ve forked the code, using it in is very similar to what is outlined in [Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules), except for the following differences: 1. Point the `source` URLs of your Terraform modules to your own Git repos, rather than the `gruntwork-io` GitHub org. 2. Point the `--repo` parameter of `gruntwork-install` to your own Git repos, rather than the `gruntwork-io` GitHub org. @@ -51,11 +50,11 @@ While forking is allowed under the Gruntwork Terms of Services, it has some down participate in issues and pull requests, and you won’t be benefiting as much from the Gruntwork community. So, whenever possible, use the code directly from the `gruntwork-io` GitHub org, as documented in -[Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules) and [Using scripts and binaries](#using_scripts_binaries). If your team relies on NPM, Docker Hub, Maven Central, +[Using Terraform Modules](/docs/intro/first-deployment/using-terraform-modules). If your team relies on NPM, Docker Hub, Maven Central, GitHub, or the Terraform Registry, using Gruntwork repos directly is no different. However, if your company completely bans all outside sources, then follow the instructions above to fork the code, and good luck!