What is the relationship between Atlantis and Gruntwork Pipelines?
1. Are Gruntwork Pipelines alternatives or complements? 2. If you wanted the Atlantis workflow of seeing `terraform plan` output in pull requests, does Gruntwork Pipelines support this? 3. If the answer to (2) is no: 1. Is support for `terraform plan` output in pull requests a reasonable Gruntwork Pipelines feature request? 1. Alternatively, could you use both Atlantis and Gruntwork Pipelines? In general, it seems like one key UX difference between Atlantis and Gruntwork Pipelines is that Atlantis outputs all feedback -- including `terraform plan` output, [infracost output](https://github.com/infracost/infracost-atlantis), and possibly others -- in the pull request, whereas Gruntwork Pipelines outputs it in the CI logs. These two UX options each have tradeoffs, so I wonder if it even makes sense to enable both options in Gruntwork Pipelines, or give customers an official documented path for enabling one or both options?
> In general, it seems like one key UX difference between Atlantis and Gruntwork Pipelines is that Atlantis outputs all feedback -- including terraform plan output, infracost output, and possibly others -- in the pull request, whereas Gruntwork Pipelines outputs it in the CI logs. These two UX options each have tradeoffs, so I wonder if it even makes sense to enable both options in Gruntwork Pipelines, or give customers an official documented path for enabling one or both options? It's important to highlight that there is a difference between Gruntwork Pipelines as a library, and Gruntwork Pipelines in the Reference Architecture. At its core, Gruntwork Pipelines is a framework for an RPC call to run infrastructure code remotely in your AWS accounts. Everything else, such as the pipeline for deploying infrastructure and reporting results to the PR, is managed by the traditional CI servers that drive the pipeline. In this regard, there is great flexibility in what pipeline you want to build, including what results get reported where. For example, you can even have the pipeline paste the `plan` outputs into Slack. In the Reference Architecture, we implement a specific pipeline that does not report any results into the PRs. This is an opinionated choice due to the security implications of making plan outputs (which may contain sensitive secrets) be available in a third party service (e.g. GitHub) in plain text. However, this does not mean that Gruntwork Pipelines does not support such an implementation. The Reference Architecture ships a specific opinionated pipeline implementation in the CI server of choice that uses Gruntwork Pipelines under the hood to run `terraform`. > Are Gruntwork Pipelines alternatives or complements? Gruntwork Pipelines is in general an alternative to Atlantis, although it can complement it in some ways. The two key differences are that: - Gruntwork Pipelines depends on a traditional CI server to drive the GitOps and pipeline. For example, you define your core infrastructure pipeline in CircleCI and rely on Gruntwork Pipelines to run the infrastructure code remotely. - In contrast, Atlantis is an all encompassing CI server optimized for terraform workflows. This means that you need to expose your Atlantis instance to VCS systems (like GitHub) directly, as it is the one performing the integration with Git. - Gruntwork Pipelines supports a wide range of infrastructure tooling, and not just running Terraform. For example, Gruntwork Pipelines can be used to build AMIs, build docker images, and in some cases, update the infrastructure code automatically to deploy a new image tag. - Note that Atlantis supports custom workflows for invoking arbitrary infrastructure, but does not have off the shelf workflows for specific infrastructure pipelines outside of Terraform. So you can have a setup where you rely on Gruntwork Pipelines for things that Atlantis doesn't support (like building an AMI and updating the infrastructure code to deploy the new image) to complement it. > If you wanted the Atlantis workflow of seeing terraform plan output in pull requests, does Gruntwork Pipelines support this? Gruntwork Pipelines does not support this out of the box, although you can make this work depending on your CI server implementation. For example, if you were using GitHub actions to drive the integration, you can set up the pipeline so that it runs the `terraform` call using Gruntwork Pipelines, and extracts the output from S3 in the next step to post it on the PR using the [gh](https://cli.github.com/) CLI. --- For more information on Gruntwork Pipelines, refer to the following resources: - [Overview of Gruntwork Pipelines](https://blog.gruntwork.io/a-ci-cd-pipeline-for-terraform-and-terragrunt-5fd346e90c89) - [Sequence diagram of Pipeline](https://github.com/gruntwork-io/terraform-aws-ci/blob/master/modules/ecs-deploy-runner/core-concepts.md#overview) - [Threat model](https://github.com/gruntwork-io/terraform-aws-ci/blob/master/modules/ecs-deploy-runner/core-concepts.md#threat-model-of-the-deploy-runner)