docs: add test step (#182)

README.md

@@ -155,188 +155,7 @@ jobs:
  INFRACOST_API_KEY: ${{ secrets.INFRACOST_API_KEY }}
 ```
 
-5. Test the integration using the following steps:
-
- 1. In your infra-as-code repo, create a new branch "infracost_test".
- 2. In the test branch, add a new file called `infracost_test.tf` at the repo root with the following example Terraform code.
- <details><summary>Example AWS Terraform code</summary>
-
- ```hcl
- provider "aws" {
- region = "us-east-1"
- skip_credentials_validation = true
- skip_requesting_account_id = true
- access_key = "mock_access_key"
- secret_key = "mock_secret_key"
- }
-
- resource "aws_instance" "my_web_app" {
- ami = "ami-005e54dee72cc1d00"
-
- instance_type = "m3.xlarge" # <<<<<<<<<< Try changing this to m5.xlarge to compare the costs
-
- tags = {
- Environment = "production"
- Service = "web-app"
- }
-
- root_block_device {
- volume_size = 1000 # <<<<<<<<<< Try adding volume_type="gp3" to compare costs
- }
- }
-
- resource "aws_lambda_function" "my_hello_world" {
- runtime = "nodejs12.x"
- handler = "exports.test"
- image_uri = "test"
- function_name = "test"
- role = "arn:aws:ec2:us-east-1:123123123123:instance/i-1231231231"
-
- memory_size = 512
- tags = {
- Environment = "Prod"
- }
- }
- ```
-
- In the above example, the Infracost pull request comment points out that:
- 1. The `root_block_device` defaults to AWS `gp2` since `volume_type` has not been specified. You should consider using `gp3` as it enables you to define performance independent of storage capacity, while providing up to 20% lower price per GB.
- 2. Also, the `m3` instance type is previous generation and should be upgraded to `m5` since that gives you a 27% saving for a more performant machine.
-
- </details>
-
- <details><summary>Example Azure Terraform code</summary>
-
- ```hcl
- provider "azurerm" {
- skip_provider_registration = true
- features {}
- }
-
- resource "azurerm_linux_virtual_machine" "my_linux_vm" {
- location = "eastus"
- name = "test"
- resource_group_name = "test"
- admin_username = "testuser"
- admin_password = "Testpa5s"
-
- size = "Standard_F16s" # <<<<<<<<<< Try changing this to Standard_F16s_v2 to compare the costs
-
- tags = {
- Environment = "production"
- Service = "web-app"
- }
-
- os_disk {
- caching = "ReadWrite"
- storage_account_type = "Standard_LRS"
- }
-
- network_interface_ids = [
- "/subscriptions/123/resourceGroups/testrg/providers/Microsoft.Network/networkInterfaces/testnic",
- ]
-
- source_image_reference {
- publisher = "Canonical"
- offer = "UbuntuServer"
- sku = "16.04-LTS"
- version = "latest"
- }
- }
-
- resource "azurerm_service_plan" "my_app_service" {
- location = "eastus"
- name = "test"
- resource_group_name = "test_resource_group"
- os_type = "Windows"
-
- sku_name = "P1v2"
- worker_count = 4 # <<<<<<<<<< Try changing this to 8 to compare the costs
-
- tags = {
- Environment = "Prod"
- Service = "web-app"
- }
- }
-
- resource "azurerm_linux_function_app" "my_function" {
- location = "eastus"
- name = "test"
- resource_group_name = "test"
- service_plan_id = "/subscriptions/123/resourceGroups/testrg/providers/Microsoft.Web/serverFarms/serverFarmValue"
- storage_account_name = "test"
- storage_account_access_key = "test"
- site_config {}
-
- tags = {
- Environment = "Prod"
- }
- }
- ```
-
- In the above example, the Infracost pull request comment points out that:
- 1. The `Standard_F16s` instance type is previous generation and should be upgraded to `Standard_F16s_v2`, since that gives you a more performant machine at a lower cost.
- 2. The App Service plan SKU name should be upgraded to a v3 plan, such as `P0v3`, since that gives you more performance and is eligible for savings plans and reserved instance pricing, opening opportunities for major savings.
-
- </details>
-
- <details><summary>Example Google Terraform code</summary>
-
- ```hcl
- provider "google" {
- region = "us-central1"
- project = "test"
- }
-
- resource "google_compute_instance" "my_instance" {
- zone = "us-central1-a"
- name = "test"
-
- machine_type = "n1-standard-16" # <<<<<<<<<< Try changing this to n1-standard-32 to compare the costs
- network_interface {
- network = "default"
- access_config {}
- }
-
- boot_disk {
- initialize_params {
- image = "debian-cloud/debian-9"
- }
- }
-
- scheduling {
- preemptible = true
- }
-
- guest_accelerator {
- type = "nvidia-tesla-t4" # <<<<<<<<<< Try changing this to nvidia-tesla-p4 to compare the costs
- count = 4
- }
-
- labels = {
- environment = "production"
- service = "web-app"
- }
- }
-
- resource "google_cloudfunctions_function" "my_function" {
- runtime = "nodejs20"
- name = "test"
- available_memory_mb = 512
-
- labels = {
- environment = "Prod"
- }
- }
- ```
-
- In the above example, the Infracost pull request comment points out that the `n1-standard-16` instance type is previous generation and should be upgraded to something like `n2-standard-16` as that gives you a more performant machine.
-
- </details>
- 3. Commit and push the change.
- 4. Send a pull request from the test branch into main/master (don't worry we won't merge it!).
- 5. 🎉 That's it! You should see a pull request comment showing the cost estimate as well as FinOps best practices that could be considered.
- 6. Feel free to change other things in the `infracost_test.tf` file. The pull request comment gets updated when new changes are pushed, e.g. the 📉 and 📈 emojis will update when costs decrease or increase. Close the pull request when you are done testing.
+5. Follow [these simple steps](https://www.infracost.io/docs/infracost_cloud/get_started/#4-send-a-pull-request) to test the integration. This is important as it ensures the CLI commands are running correctly in your workflow 👌
 
 6. [Infracost Cloud](https://dashboard.infracost.io) is our SaaS product that builds on top of Infracost open source. It enables team leads, managers and FinOps practitioners to setup [tagging policies](https://www.infracost.io/docs/infracost_cloud/tagging_policies/), [guardrails](https://www.infracost.io/docs/infracost_cloud/guardrails/) and [best practices](https://www.infracost.io/docs/infracost_cloud/cost_policies/) to help guide the team. For example, you can check for required tag keys/values, or suggest switching AWS gp2 volumes to gp3 as they are more performant and cheaper.