heroku/terraform-provider-heroku

Terraform Heroku provider

Terraform Provider Heroku

This provider is used to configure resources supported by the Heroku Platform API.

See the official documentation to use this provider in a Terraform configuration.

Requirements

• Terraform 1.x
• Go 1.19 (to build the provider plugin)

Usage

The configuration should specify version 5:

provider "heroku" {
  version = "~> 5.0"
}

See Upgrading guide for major version migration help.

👓📚 For more usage info, see Heroku Provider docs.

Development

If you wish to work on the provider, you'll first need Go installed on your machine (version 1.16+ is required). You'll also need to correctly setup a GOPATH, as well as adding $GOPATH/bin to your $PATH.

Clone the Provider

With Go language, the repository must be cloned to a specific path in $GOPATH/src that matches its module import path.

mkdir -p $GOPATH/src/github.com/heroku
cd $GOPATH/src/github.com/heroku
git clone [email protected]:heroku/terraform-provider-heroku

Build the Provider

To compile the provider, run make build. This will build the provider and put the provider binary in the $GOPATH/bin directory.

$ make build
...
$ $GOPATH/bin/terraform-provider-heroku
...

Using the Provider

To use the dev provider with local Terraform, configure a dev override pointing to the directory where terraform-provider-heroku can be found:

cat << TRC >> ~/.terraformrc
provider_installation {
  dev_overrides {
    "heroku/heroku" = "$GOPATH/bin"
  }
  direct {}
}
TRC

Terraform Versions Prior to 0.13

Copy the freshly built plugin into Terraform's local plugins directory:

cp $GOPATH/bin/terraform-provider-heroku ~/.terraform.d/plugins/

Set the Heroku provider without a version constraint:

provider "heroku" {}

Then, initialize Terraform:

terraform init

Testing

Please see the TESTING guide for detailed instructions on running tests.

Updating or adding dependencies

This project uses Go Modules for dependency management.

Dependencies can be added or updated as follows:

$ GO111MODULE=on go get github.com/some/module@release-tag
$ GO111MODULE=on go mod tidy
$ GO111MODULE=on go mod vendor

This example will fetch a module at the release tag and record it in your project's go.mod and go.sum files. It's a good idea to tidy up afterward and then copy the dependencies into vendor/.

If a module does not have release tags, then module@master can be used instead.

Removing dependencies

Remove all usage from your codebase and run:

$ GO111MODULE=on go mod tidy
$ GO111MODULE=on go mod vendor

terraform-provider-heroku's Issues

Error Retrieving Heroku Addon -- Invalid Credentials Provided

Description

I have a Heroku app provisioned via Terraform. That part works great.
The Heroku instance has a Papertrail add-on.
Importing the add on works fine. I see the correct id and attributes in the .tfstate.

After importing, running terraform plan or terraform refresh gives the error:

Error refreshing state: 1 error(s) occurred:

* heroku_addon.papertrail: heroku_addon.papertrail: Error retrieving addon: Get https://api.heroku.com/addons/papertrail-transparent-47380: Invalid credentials provided.

Terraform Version

v0.10.2

Affected Resource(s)

• heroku_addon

Terraform Configuration Files

provider "heroku" {
  email   = "${var.heroku_email}"
  api_key = "${var.heroku_api_key}"
}

# Create a new Heroku app
resource "heroku_app" "social_proxy" {
  name    = "${var.hk_app_name}"
  region  = "us"
  stack   = "cedar-14"

  config_vars {
    ---- snip ----
  }
}

resource "heroku_addon" "papertrail" {
  count = "${var.provision_papertrail_addon}" # boolean to add papertrail or not
  app  = "${heroku_app.social_proxy.name}"
  plan = "papertrail:choklad"
}

Expected Behavior

Heroku add-on state should be retrieved from https://api.heroku.com/addons/papertrail-transparent-47380 using same API key used when importing and when managing the Heroku app itself.

Actual Behavior

Terraform gets an error response from https://api.heroku.com/addons/papertrail-transparent-47380 indicating that invalid credentials were provided.

Steps to Reproduce

terraform plan

Important Factoids

1. Using cURL, I'm able to retrieve the add-on state by sending the API key in an Authorization header.
2. If I send no Authorization header, I get an error saying "There were no credentials in your Authorization header.". This implies that Terraform is sending something for authorization but it's incorrect.

Support for ~/.netrc authentication

I think it would be a nice addition to support .netrc authentication.

Here is a Heroku go client issue that concluded clients should handle netrc: bgentry/heroku-go#4

There is a client library already included to handle netrc but it doesn't seem to be used in this provider: https://github.com/terraform-providers/terraform-provider-heroku/tree/7948ef837c3f00f0fe672fd64bb679e67cdd09e8/vendor/github.com/bgentry/go-netrc

Heroku docs on netrc: https://devcenter.heroku.com/articles/authentication#netrc-file-format

Addon attachments are always re-created

Terraform Version

0.11.7

Affected Resource(s)

Please list the resources as a list, for example:

• heroku_addon_attachment

Terraform Configuration Files

heroku_app "app1" {
  ...
}

heroku_addon "addon1" {
  app = "${heroku_app.app1.name}"
  ...
}

heroku_app "app2" {
  ...
}

heroku_addon_attachment "addon1-app2" {
  app_id = "${heroku_app.app2.id}"
  addon_id = "${heroku_addon.addon1.id}"
}

Expected Behavior

Once applied, re-planning should require no changes

Actual Behavior

Plan includes:

-/+ heroku_addon_attachment.addon1-app2 (new resource required)
      id:       "[UUID 1 removed]" => <computed> (forces new resource)
      addon_id: "[UUID 2 removed]" => "[addon1 name removed]" (forces new resource)
      app_id:   "app2" => "app2"
      name:     "MY_NAME" => "MY_NAME"

Steps to Reproduce

1. terraform apply
2. terraform plan

Important Factoids

I think this is because the id attribute of the heroku_addon is its name, not its UUID. Therefore, when interpolating the HCL, terraform thinks the heroku_addon_attachment should be between app2 and addon1.name, but in the state it's between app2 and addon1's UUID which is not in the state at all. Therefore, every plan requires re-creating the addon attachment.

References

I think this was introduced by #39 .

Missing resources in heroku-provider

This issue was originally opened by @abtris as hashicorp/terraform#5649. It was migrated here as part of the provider split. The original body of the issue is below.

---

We use Heroku very extensively and I try use terraform for describing our apps and these things are missing.

• App Feature - preboot is important feature and more (log-runtime-metrics, runtime-dyno-metadata)
• Account Feature - this is used for many labs things (metrics-beta) - optional
• Formation - I see open PR

heroku_app changes after provisioning don't matter

organization, personal and region apply, but don't change anything after the app has been created

Updated config variable handling (0.1.1) fails with vars from addons

Terraform Version

Terraform v0.10.8

Affected Resource(s)

• heroku_app

Terraform Configuration Files

Start with:

provider "heroku" {
  version = "0.1.1"
}

resource "random_id" "app_name_suffix" {
  byte_length = 4
}

resource "heroku_app" "default" {
  name   = "test-${random_id.app_name_suffix.hex}"
  region = "us"

  config_vars {
    A = "1"
    B = "2"
    C = "3"
  }
}

resource "heroku_addon" "database" {
  app  = "${heroku_app.default.name}"
  plan = "heroku-postgresql:hobby-basic"
}

Steps to Reproduce

(Given config above)

1. terraform init
2. terraform apply
3. terraform plan
4. terraform apply

Step 3 shows:

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  ~ heroku_app.default
      config_vars.0.%:            "4" => "3"
      config_vars.0.DATABASE_URL: "postgres://vslgcepyvutomi:[e-mail]:5432/d6tcmecqio7rgu" => ""


Plan: 0 to add, 1 to change, 0 to destroy.

------------------------------------------------------------------------

Step 4 shows:

heroku_app.default: Modifying... (ID: test-588eef73)
  config_vars.0.%:            "4" => "3"
  config_vars.0.DATABASE_URL: "postgres://vslgcepyvutomi:[e-mail]:5432/d6tcmecqio7rgu" => ""

Error: Error applying plan:

1 error(s) occurred:

* heroku_app.default: 1 error(s) occurred:

* heroku_app.default: Error updating config vars: Patch https://api.heroku.com/apps/test-588eef73/config-vars: Cannot overwrite attachment values DATABASE_URL.

Error when Build source path matches current directory

Terraform & Heroku Provider Version

Terraform v0.11.10
+ provider.heroku v1.7.1

Affected Resource(s)

Please list the resources as a list, for example:

• heroku_build

Terraform Configuration Files

resource "heroku_app" "foobar" {
    name   = "foobar"
    region = "us"
}

resource "heroku_build" "foobar" {
  app = "${heroku_app.foobar.id}"

  source = {
    path = "./"
  }
}

Debug Output

Error: Error running plan: 1 error(s) occurred:

* heroku_build.foobar_docker: 1 error(s) occurred:

* heroku_build.foobar_docker: Error generating build source tarball ./:
  Error generating build source tarball source-6939a70b-4a9f-f53a-95ae-08de1429ed1a.tar.gz of ./:
  archive/tar: write too long

Expected Behavior

The Build is created successfully.

Actual Behavior

The Build throws an error.

Steps to Reproduce

1. terraform apply

Important Factoids

The source.path is the same directory containing the Terraform config.

Terraform sometimes creates a Heroku Cert, then gets a conflict error

Terraform Version

Terraform v0.11.1
provider.heroku v0.1.2

Affected Resource(s)

heroku_cert

Terraform Configuration Files

resource "heroku_cert" "ssl_certificate" {
  app               = "${heroku_app.default.name}"
  certificate_chain = "${file("server.crt")}"
  private_key       = "${file("server.key")}"
  depends_on        = "heroku_addon.ssl"
}

Expected Behavior

Terraform successfully creates a Heroku Cert resource and records it in the state file.

Actual Behavior

Intermittently, when creating a Heroku Cert resource, we get this error:

* heroku_cert.cert: Error creating SSL endpoint: Post https://api.heroku.com/apps/my-super-application/ssl-endpoints: Conflict

I can confirm that this ssl certificate doesn't exist prior to the Terraform run, is not duplicated in the Terraform code and does exist after the run has complete - almost like Heroku is creating the resource, then telling us it already exists(!).

I can also confirm that deleting this resource from Heroku, then allowing Terraform to recreate it, works. Importing the resource also works as a mitigation of this issue.

Implement teams resource

Heroku Provisioner doesn't properly validate variable syntax in a config_vars block

This issue was originally opened by @wdullaer as hashicorp/terraform#5662. It was migrated here as part of the provider split. The original body of the issue is below.

---

I had a rather large terraform plan containing multiple providers.

One of the heroku app resources had the following in the config_vars block

resource "heroku_app" "web" {
  name = "awesome-app"
  config_vars = {
    USERNAME = "${my_username}"
  }
}

Notice how it says "${my_username}" rather than "${var.my_username}"
Due to the size of the total project, I didn't notice this.
terraform validate didn't throw any errors
terraform plan worked just fine

It finally crashen when trying to apply the changes with this rather bizar error

panic: interface conversion: interface {} is nil, not map[string]interface {}                                                                                                                                     
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:                                                                                                                                                            
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: goroutine 62 [running]:                                                                                                                                    
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: panic(0xa74da0, 0xc820224100)                                                                                                                              
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/go/src/runtime/panic.go:464 +0x3e6                                                                                                                   
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: github.com/hashicorp/terraform/builtin/providers/heroku.resourceHerokuAppRead(0xc8202d8540, 0xb3a8c0, 0xc82017c660, 0x0, 0x0)                              
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/gopath/src/github.com/hashicorp/terraform/builtin/providers/heroku/resource_heroku_app.go:290 +0xf0b                                                 
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: github.com/hashicorp/terraform/builtin/providers/heroku.resourceHerokuAppUpdate(0xc8202d8540, 0xb3a8c0, 0xc82017c660, 0x0, 0x0)                            
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/gopath/src/github.com/hashicorp/terraform/builtin/providers/heroku/resource_heroku_app.go:376 +0x625                                                 
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: github.com/hashicorp/terraform/helper/schema.(*Resource).Apply(0xc820107880, 0xc820493b00, 0xc820491de0, 0xb3a8c0, 0xc82017c660, 0xc820493c01, 0x0, 0x0)   
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/gopath/src/github.com/hashicorp/terraform/helper/schema/resource.go:152 +0x3b9                                                                       
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: github.com/hashicorp/terraform/helper/schema.(*Provider).Apply(0xc820344ff0, 0xc820401280, 0xc820493b00, 0xc820491de0, 0x1, 0x0, 0x0)                      
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/gopath/src/github.com/hashicorp/terraform/helper/schema/provider.go:162 +0x1ed                                                                       
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: github.com/hashicorp/terraform/rpc.(*ResourceProviderServer).Apply(0xc8203b49c0, 0xc8204b1a40, 0xc820491e30, 0x0, 0x0)                                     
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/gopath/src/github.com/hashicorp/terraform/rpc/resource_provider.go:323 +0x76                                                                         
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: reflect.Value.call(0xa0a940, 0xaf20f8, 0x13, 0xb3e610, 0x4, 0xc8201ffed8, 0x3, 0x3, 0x0, 0x0, ...)                                                         
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/go/src/reflect/value.go:435 +0x120d                                                                                                                  
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: reflect.Value.Call(0xa0a940, 0xaf20f8, 0x13, 0xc8201ffed8, 0x3, 0x3, 0x0, 0x0, 0x0)                                                                        
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/go/src/reflect/value.go:303 +0xb1                                                                                                                    
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: net/rpc.(*service).call(0xc820107a00, 0xc8201079c0, 0xc8203a1850, 0xc820341880, 0xc8203b49e0, 0x91f5a0, 0xc8204b1a40, 0x16, 0x91f600, 0xc820491e30, ...)   
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/go/src/net/rpc/server.go:383 +0x1c2                                                                                                                  
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku: created by net/rpc.(*Server).ServeCodec                                                                                                                    
2016/03/16 16:02:52 [DEBUG] terraform-provider-heroku:  /opt/go/src/net/rpc/server.go:477 +0x49d                                                                                                                  
2016/03/16 16:02:52 [DEBUG] root: eval: *terraform.EvalWriteState                                                                                                                                                 
2016/03/16 16:02:52 [DEBUG] root: eval: *terraform.EvalApplyProvisioners                                                                                                                                          
2016/03/16 16:02:52 [DEBUG] root: eval: *terraform.EvalIf                                                                                                                                                         
2016/03/16 16:02:52 [DEBUG] root: eval: *terraform.EvalWriteDiff                                                                                                                                                  
2016/03/16 16:02:52 [DEBUG] root: eval: *terraform.EvalIf                                                                                                                                                         
2016/03/16 16:02:52 [DEBUG] root: eval: *terraform.EvalWriteState                                                                                                                                                 
2016/03/16 16:02:52 [DEBUG] root: eval: *terraform.EvalApplyPost                                                                                                                                                  
2016/03/16 16:02:52 [DEBUG] /usr/local/bin/terraform-provider-heroku: plugin process exited                                                                                                                       
2016/03/16 16:02:52 [ERROR] root: eval: *terraform.EvalApplyPost, err: 1 error(s) occurred:                                                                                                                       

* heroku_app.integration: unexpected EOF                                                                                                                                                                          
2016/03/16 16:02:52 [ERROR] root: eval: *terraform.EvalSequence, err: 1 error(s) occurred:                                                                                                                        

* heroku_app.integration: unexpected EOF                                                                                                                                                                          
2016/03/16 16:02:52 [ERROR] root: eval: *terraform.EvalOpFilter, err: 1 error(s) occurred:                                                                                                                        

* heroku_app.integration: unexpected EOF                                                                                                                                                                          
2016/03/16 16:02:52 [ERROR] root: eval: *terraform.EvalSequence, err: 1 error(s) occurred:                                                                                                                        

* heroku_app.integration: unexpected EOF                                                                                                                                                                          
2016/03/16 16:02:52 [TRACE] [walkApply] Exiting eval tree: heroku_app.integration                                                                                                                                 
2016/03/16 16:02:52 [DEBUG] vertex provider.heroku (close), got dep: heroku_app.integration                                                                                                                       
2016/03/16 16:02:52 [DEBUG] vertex root, got dep: provider.heroku (close)                                                                                                                                         
2016/03/16 16:02:52 [DEBUG] vertex root, got dep: provider.aws (close)                                                                                                                                            
2016/03/16 16:02:52 [DEBUG] waiting for all plugin processes to complete...                                                                                                                                       
2016/03/16 16:02:52 [DEBUG] /usr/local/bin/terraform-provider-aws: plugin process exited      

It took me a while/day to figure out that there was a variable with an invalid syntax. I suppose the terraform parser should catch this.

shield attribute not imported for spaces

Terraform Version

Terraform v0.11.7
+ provider.external v1.0.0
+ provider.google v1.14.0
+ provider.heroku v1.0.0
+ provider.null v1.0.0

Affected Resource(s)

• heroku_space

Terraform Configuration Files

variable space_name {}

resource "heroku_space" "default" {
  name              = "${var.space_name}"
  organization      = "my-org"
  region            = "virginia"
  trusted_ip_ranges = ["0.0.0.0/0"]
}

Debug Output

-/+ heroku_space.default (new resource required)
      id:                          "my-space-uuid" => <computed> (forces new resource)
      name:                        "my-space" => "my-space"
      organization:                "my-org" => "my-org"
      outbound_ips.#:              "4" => <computed>
      region:                      "virginia" => "virginia"
      shield:                      "" => "false" (forces new resource)
      trusted_ip_ranges.#:         "1" => "1"
      trusted_ip_ranges.217649824: "0.0.0.0/0" => "0.0.0.0/0"

Actual Behavior

After importing an existing space successfully with terraform import heroku_space.default $UUID and then running terraform plan, it immediately wanted to destroy and recreate the space due to the shield attribute needing to be set. It looks like https://github.com/terraform-providers/terraform-provider-heroku/pull/63 added this attribute, but didn't update resourceHerokuSpaceRead to pull in the new shield value on import.

Steps to Reproduce

1. Create a fresh non-shield Heroku space
2. Import that space with terraform import heroku_space.default $UUID
3. Run terraform plan

Create a resource for creating Heroku teams

https://devcenter.heroku.com/articles/platform-api-reference#team-create

Terraform tries to delete DATABASE_URL env var.

Hi,

I have a config with a database addon which generated DATABASE_URL after the first time I ran terraform apply and everything was ok, the DATABASE_URL was generated and added to heroku app but then I noticed I need to change some of the env vars so I edited the terraform file and after running terraform plan the output showed me it would change DATABASE_URL to an empty string.

Here is what I have in config vars

  config_vars {
    HANAMI_ENV = "production",
    NODE_MODULES_CACHE = "false",
    NPM_CONFIG_PRODUCTION = "false",
  }

As you can see there is no DATABASE_URL specified since it is computed.

And here is the output of terraform plan

~ heroku_app.staging
      config_vars.0.%:                     "4" => "3"
      config_vars.0.DATABASE_URL:          "postgres://agextps..." => ""
      config_vars.0.NODE_MODULES_CACHE:    "0" => "false"
      config_vars.0.NPM_CONFIG_PRODUCTION: "0" => "false"

heroku_domain does not gracefully handle missing resources

It seems that the heroku_domain does not gracefully handle situations where the previously-created domain has been deleted outside of Terraform. I think I also saw the same issue when trying to add a custom domain to an app via Terraform for the first time, but the domain name already exists on the app.

I am not certain about the intended behaviour within Terraform ecosystem about the latter (trying to create something that already exists), but the former definitely seems like a bug to me (trying to read the state of a resource which no longer exists or trying to delete a resource which no longer exists).

Looking at the source code, the error seems to come from here:

https://github.com/terraform-providers/terraform-provider-heroku/blob/aa9862241aa9aa3e5fed08bc1a9166b3f54bd6c1/heroku/resource_heroku_domain.go#L98-L101

And I see similar error handling pattern when trying to delete the domain:

https://github.com/terraform-providers/terraform-provider-heroku/blob/aa9862241aa9aa3e5fed08bc1a9166b3f54bd6c1/heroku/resource_heroku_domain.go#L87-L89

And, as a side note - while not actually observing this behaviour, this error handling pattern is also present in the heroku_pipeline, which would indicate a similar problem as described above:

https://github.com/terraform-providers/terraform-provider-heroku/blob/aa9862241aa9aa3e5fed08bc1a9166b3f54bd6c1/heroku/resource_heroku_pipeline.go#L102-L104

Terraform Version

Terraform v0.11.3

• provider.heroku v0.1.2

Affected Resource(s)

• heroku_domain

Terraform Configuration Files

resource "heroku_app" "api" {
  name   = "example-api-development"
  region = "eu"

  buildpacks = [
    "heroku/nodejs",
  ]

  organization {
    name = "example"
  }
}

resource "heroku_domain" "api" {
  app      = "${heroku_app.api.name}"
  hostname = "api-development.example.com"
}

Expected Behavior

The domain should have been recognised as missing and marked for creation.

Actual Behavior

terraform plan panicked because the resource which was previously created by terraform (and was thus in the state) no longer exists.

Steps to Reproduce

1. Using Terraform, create a Heroku app and attach a custom domain with the heroku_domain resource
2. Remove the custom domain from the app via Heroku dashboard
3. Run terraform plan again
4. Observe crash

Important Factoids

None that I am aware of.

Support Pipeline Ownership

Terraform Version

❯ terraform -v
Terraform v0.11.7
+ provider.heroku v1.1.0

Affected Resource(s)

• heroku_pipeline

Terraform Configuration Files

resource "heroku_app" "production" {
  name = "test-app-production"
}

Expected Behavior

heroku_pipeline should have a key to assign ownership of a pipeline. Pipelines without an owner are deprecated according to the heroku docs and show an warning banner: https://devcenter.heroku.com/articles/pipeline-ownership-transition

Actual Behavior

pipelines are created without an owner.

Steps to Reproduce

1. terraform apply

Fix TestAccHerokuBuild_LocalSourceDirectory

The following test is failing on Jenkins and locally:

20:48:12 --- FAIL: TestAccHerokuBuild_LocalSourceDirectory (13.45s)
20:48:12 	testing.go:518: Step 0 error: Check failed: Check 2/2 error: heroku_build.foobar: Attribute 'local_checksum' expected "SHA256:2962c248919d5b26dae2582a14ea1e518120453291756c98e28519da78d0880c", got "SHA256:1b4ba932b26d5d1c0648d7303cb87e87994bf395006ab3f143ae4e9f120fea30"

heroku_addon_attachment uses app_id instead of app

All the heroku resources that depend on heroku_app take app as a parameter; however, heroku_addon_attachment (added in #19) takes app_id instead. While this is easy to workaround, it is inconsistent with all the other resources.

The same is true for the addon_id parameter, but probably less of an issue since it's less prevalent.

Terraform Version

v0.11.7

Affected Resource(s)

Please list the resources as a list, for example:

• heroku_addon_attachment

Terraform Configuration Files

See below for relevent snippets

Expected Behavior

Something like this should work:

resource "heroku_addon_attachment" "addons_kafka_01" {
  addon = "${heroku_addon.kafka_01.id}"
  app = "${heroku_app.addons_app.name}"
  name = "KAFKA_01"
}

Actual Behavior

Instead, you have to do this:

resource "heroku_addon_attachment" "addons_kafka_01" {
  addon_id = "${heroku_addon.test.id}"
  app_id = "${heroku_app.addons_app.name}"
  name = "TEST_01"
}

Steps to Reproduce

n/a

Important Factoids

n/a

References

#19 cc: @JamesBelchamber

Feature request: Heroku App access list

This issue was originally opened by @DmitryMihailov as hashicorp/terraform#15499. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Dear Terraform community!

Terraform has almost everything for configuring Heroku environments - love it. But, I've noticed that there is no attributes to define list of users with permissions to access Heroku app.

I've done this through bash recently:

      while read -r email permissions; do
        heroku access:add -a "${HEROKU_APP_NAME}" "${email}" --permissions "${permissions}" || true
      done <"${HEROKU_APP_ACCESS_LIST}"

Plain text access list file looks like this:

[email protected] view,deploy,operate,manage
[email protected] view,deploy,operate
[email protected] view,deploy,operate

That's just an example for your inspiration!
Thank you!

PS At least there is lock attribute 🔥

Add Exponential Backoff When adding Heroku Domain

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

• v0.11.7

Affected Resource(s)

• heroku_domain

Terraform Configuration Files

resource "heroku_app" "app" {
  name = "meh"

  region = "validregion"
  space  = "validspace"
}

resource "heroku_domain" "app" {
  app      = "${heroku_app.app.name}"
  hostname = "validfqdn"
}

Output

heroku_domain.app: 1 error(s) occurred:

• heroku_domain.app: Post https://api.heroku.com/apps/meh/domains: App meh is being provisioned. Please try again later.

Expected Behavior

It should wait until the app completes provisioning before trying to apply the domain change

Actual Behavior

Failed apply

Removing an app from Heroku breaks existing resources tied to that app

Terraform Version

Terraform v0.11.8
+ provider.heroku v1.4.0

Affected Resource(s)

Please list the resources as a list, for example:

• heroku_drain
• Any other resource that applies to an app

Terraform Configuration Files

resource "heroku_drain" "drain" {
    app = "${var.heroku_app}"
    url = "${var.url}"
}

Expected Behavior

Terraform should remove the drain from the state file

Actual Behavior

Error: Error refreshing state: 2 error(s) occurred:

* app_name.heroku_drain.drain: heroku_drain.drain: Error retrieving drain: Get https://api.heroku.com/apps/app_name/log-drains/drain-uuid: Couldn't find that app.

Steps to Reproduce

1. Create an application manually
2. Create a drain with Terraform and point it to the application
3. Delete the application manually
4. Remove the drain from HCL

Update vendored version of Terraform Core

I believe terraform is now on v0.11+ and the vendored version is v0.10 (https://github.com/terraform-providers/terraform-provider-heroku/blob/master/vendor/vendor.json#L395).

It is probably a good idea to update the version to get the latest changes of terraform core.

Implement App Feature Resource

https://devcenter.heroku.com/articles/platform-api-reference#app-feature

provider/heroku: Error on refresh if App addon is missing

This issue was originally opened by @catsby as hashicorp/terraform#14287. It was migrated here as part of the provider split. The original body of the issue is below.

---

Resource heroku_addon seems to throw an error if the App addon is deleted/removed out of band from Terraform:

• https://github.com/hashicorp/terraform/blob/master/builtin/providers/heroku/resource_heroku_addon.go#L98

The Read method (resourceHerokuAddonRead) should detect a specific "App addon no longer exists" type error, remove the app addon from state with d.SetId(""), and log the removal.

Could also implement an Exists method, like so:

• https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_kms_key.go#L373

heroku_space_inbound_ruleset using counts isn't possible

terraform -v
Terraform v0.11.8
+ provider.heroku v1.3.0

Affected Resource(s)

• heroku_space_inbound_ruleset

Terraform Configuration Files

locals {
  inbound_rules = ["61.120.150.0/28", "62.17.146.0/26"]
}

resource "heroku_space" "test_talbright" {
  name         = "test-talbright"
  organization = "${var.organization}"
  region       = "${var.region}"
  shield       = "false"
}

resource "heroku_space_inbound_ruleset" "ruleset" {
  count = "${length(local.inbound_rules)}"
  space = "test-talbright"

  rule {
    action = "allow"
    source = "${element(local.inbound_rules,count.index)}"
  }
}

Output

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  + heroku_space_inbound_ruleset.ruleset[0]
      id:                     <computed>
      rule.#:                 "1"
      rule.1473555236.action: "allow"
      rule.1473555236.source: "61.120.150.128/28"
      space:                  "test-talbright"

  + heroku_space_inbound_ruleset.ruleset[1]
      id:                     <computed>
      rule.#:                 "1"
      rule.2428952940.action: "allow"
      rule.2428952940.source: "62.17.146.128/26"
      space:                  "test-talbright"


Plan: 2 to add, 0 to change, 0 to destroy.

Expected Behavior

heroku_space_inbound_ruleset rules can't be generated by using a count with a list. This means every single rule has to be hardcoded 😢

Actual Behavior

heroku_space_inbound_ruleset with count only one rule is generated, the last item in the list. This is because each API call to PUT /spaces/{space-name}/inbound-ruleset replaces/overwrites the ruleset.

Perhaps the resource should either be modeled closer to https://www.terraform.io/docs/providers/aws/r/security_group_rule.html, or a new resource should be created to encapsulate the same approach.

Ability to hide config vars from Plan Output

From @joslynesser,

To give context on how we use this proposed change in our private fork:

Without a vault cluster (or some other centralized secret store), one can leverage heroku config vars and distribute those secrets to every app across all regions with terraform. This keeps a secret source to a single location and avoids human error.

One create sa heroku app that houses these secrets, and then fetch values using all_config_vars from that central app to distribute the secrets to all other apps. This because our backend terraform state only exists in memory and is encrypted at rest in S3. Secrets are fetched in memory on the terraform run from the state that houses the secrets app, and then set on all apps needing that secret value.

Therefore, we need to ensure our secrets are not plain texted shown in a plan/apply output on say a CI tool.

Create a resource for managing space access

https://devcenter.heroku.com/articles/platform-api-reference#space-access

Feature request: Heroku App access list

Dear Terraform community!

Terraform has almost everything for configuring Heroku environments - love it. But, I've noticed that there is no attributes to define list of users with permissions to access Heroku app.

I've done this through bash recently:

      while read -r email permissions; do
        heroku access:add -a "${HEROKU_APP_NAME}" "${email}" --permissions "${permissions}" || true
      done <"${HEROKU_APP_ACCESS_LIST}"

Plain text access list file looks like this:

[email protected] view,deploy,operate,manage
[email protected] view,deploy,operate
[email protected] view,deploy,operate

That's just an example for your inspiration!
Thank you!

PS At least there is lock attribute 🔥

Terraform crashes when attempting to import a cert with an invalid ID

If the ID lacks a :, terraform crashes.

Terraform v0.11.10
+ provider.heroku v1.6.0

Affected Resource(s)

• heroku_cert

Terraform Configuration Files

resource "heroku_app" "default" {
  name = "test-app"
}


# Establish certificate for a given application
resource "heroku_cert" "ssl_certificate" {
  app               = "${heroku_app.default.name}"
}

Debug Output

(skipped)

Panic Output

https://gist.github.com/bpo/57c57778ef7bf1489b9551693cd01f7b

Expected Behavior

I should receive an error informing me that my cert ID is invalid

Actual Behavior

Terraform crashed

Steps to Reproduce

1. terraform import heroku_cert.ssl_certificate foo

References

• https://github.com/terraform-providers/terraform-provider-heroku/blob/620d1ebcd3608b5337bd9a5f958ddeb769b57709/heroku/resource_heroku_cert.go#L57

deploying the application on the resource

I've got a simple terraform file

variable "heroku_api_key" {}

provider "heroku" {
    email = "[email protected]"
    api_key = "${var.heroku_api_key}"
}

resource "heroku_app" "judge_re" {
    name = "judge-re"
    region = "us"

    buildpacks = [
        "heroku/java"
    ]
}

When I run terraform apply it successfully creates the infrastructure - the applicaiton and required buildpack. My question is - can I deploy the application (sources with Procfile) too? Or I should use separate tools like Jenkins or Travis to do that?

heroku_formation does not support Free or Hobby dyno types

Terraform Version

0.11.2

Affected Resource(s)

• heroku_formation

Terraform Configuration Files

resource "heroku_formation" "formation" {
  app      = "myfreeapp"
  type     = "web"
  quantity = "1"
  size     = "Free"
}

Panic Output

https://gist.github.com/dtaylor-sfdc/097fc83f1959cf4d86cff70ec7c29119

Expected Behavior

Create a heroku_formation resource with a free dyno.

Actual Behavior

Crash due to unexpected EOF.

References

See:

https://devcenter.heroku.com/articles/dyno-types
https://devcenter.heroku.com/articles/heroku-enterprise#available-dyno-types

for all supported dyno types. Notice that the non-enterprise accounts include "Free" and "Hobby".

heroku_app in private space won't lock

terraform -v
Terraform v0.11.8
+ provider.heroku v1.3.0

Affected Resource(s)

• heroku_space

Terraform Configuration Files

resource "heroku_app" "external_cc_app" {
  name   = "foo-app"
  region = "${var.region}"
  stack  = "heroku-16"
  space  = "foo-space"

  organization {
    name   = "${var.organization}"
    locked = true
  }

}

Expected Behavior

heroku_app should be locked.

Actual Behavior

heroku_app is not locked.

heroku_config resource

Currently, the only way to manage config variables on a heroku app is via the heroku_app resource. ie:

resource "heroku_app" "my_app" {
  name = "my-app"
  config_vars {
    CONFIG_VAR = "value"
  }
}

This approach has a few problems:

1. It results in centralization of config vars. All config vars coming in from any other generated resources get set in one place. This means that the setting of a config var on an app can be far away from the place the var is defined, which may make it harder to follow the flow.

2. It makes it impossible to set config vars on an app that isn't managed by terraform. This is somewhat dangerous, since it means that even if all you really want to do is set a few config vars on an app, you're obligated to give your script the ability to manage other properties of the app as well (and even to destroy or create it).

Possible Solution: heroku_config resource

We add a heroku_config resource, like this:

resource "heroku_config" "my_config_vars" {
  app = "my-app"
  config_vars {
    CONFIG_VAR = "value"
  }
}

You can create multiple resources to configure different sets of config vars on the same app. It also still supports management of many config vars in the same resource, which is good for keeping things minimally verbose (my initial idea was to have one resource per config var, but I feel like this is a bit better).

Caveats

Config var conflicts

What to do if config vars conflict across multiple resources? I suggest we detect this situation and fail if it happens.

Release Explosion

What to do about possibly generating lots of releases and restarting apps repeatedly?
I suggest we defer the actual setting of config vars until the end of a run. Is this possible? If it's not possible, I suggest that we just document it - I don't think this is necessarily a blocker.

Create a resource for inbound rulesets on Heroku Private Spaces

https://devcenter.heroku.com/articles/platform-api-reference#inbound-ruleset

heroku_app.vault net/http: TLS handshake timeout

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

Terraform v0.11.7
+ provider.heroku v1.0.1

Affected Resource(s)

Please list the resources as a list, for example:

• heroku_app

Terraform Configuration Files

# Configure the Heroku provider
provider "heroku" {
  email   = "${var.heroku_email}"
  api_key = "${var.heroku_api_key}"
}

resource "heroku_app" "vault" {
  name   = "vault-${var.hub_branch}"
  region = "${var.heroku_region}"

  config_vars {

  }

  buildpacks = [
    "https://github.com/deeplearninc/heroku-buildpack-vault"
  ]
}

Debug Output

https://gist.github.com/holyketzer/84285cb263b48dd41085a7e6875101ae

Expected Behavior

It should create heroku app

Actual Behavior

it fails with TLS handshake timeout error

Steps to Reproduce

terraform apply

heroku_addon_attachment resource saves add-on ID using add-on name

Terraform Version

0.11.2

Affected Resource(s)

• heroku_addon_attachment

Terraform Configuration Files

resource "heroku_app" "default" {
  name = "test-app"
}

resource "heroku_addon" "sumologic" {
  app  = "${heroku_app.default.name}"
  plan = "sumologic:free"
}

resource "heroku_addon_attachment" "sumologic" {
  app_id  = "${heroku_app.default.id}"
  addon_id = "${heroku_addon.sumologic.id}"
}

Debug Output

Try planning and applying the same add-on attachment multiple times. See below for an example of a second run. Note that the addon_id in the state file has addon_name as its value, which is incorrect and results in forcing a new resource on every plan.

Terraform will perform the following actions:

heroku_addon_attachment.sumologic (new resource required)
       id:       "5382910f-92d4-4952-bc39-a92de2f87a72" => <computed> (forces new resource)
       addon_id: "sumologic-cubic-53500" => "1c7aa1ef-a6fc-47a4-abbb-b23512fc15a7" (forces new resource)
       app_id:   "sfdc-cb-rt-stg-ore" => "sfdc-cb-rt-stg-ore"
       name:     "SUMOLOGIC" => <computed>

Plan: 1 to add, 0 to change, 1 to destroy.

Expected Behavior

A second plan should show no changes.

Actual Behavior

After the first plan and apply, every subsequent plan believes the attachment ID has changed and, since that is not an attribute that can be modified, plans to destroy and create the same attachment every time.

Steps to Reproduce

1. terraform apply
2. terraform apply

Important Factoids

This is due to this line.

Likely a copy-and-paste error introduced by copying the app ID/name line above, which can be used interchangeably for apps, but not for other resources.

Broken space-related acceptance tests

Two spaces-related acceptance tests are broken:

• TestAccHerokuApp_Space
• TestAccHerokuSpace_Basic

To reproduce:

export TF_ACC=true
export HEROKU_EMAIL=...
export HEROKU_API_KEY=...
export HEROKU_ORGANIZATION=...
export HEROKU_SPACES_ORGANIZATION=...
go build && go test -timeout 300m -v ./heroku -run TestAccHerokuApp_Space
go build && go test -timeout 300m -v ./heroku -run TestAccHerokuSpace_Basic

Results:

--- FAIL: TestAccHerokuSpace_Basic (432.55s)
	testing.go:434: Step 1 error: After applying this step, the plan was not empty:

		DIFF:

		UPDATE: heroku_space.foobar
		  trusted_ip_ranges.#: "0" => "2"
		  trusted_ip_ranges.0: "" => "8.8.8.8/32"
		  trusted_ip_ranges.1: "" => "8.8.8.0/24"

		STATE:

		heroku_space.foobar:
		  ID = 681d984f-755d-47ac-8d4f-c0750aabb2ef
		  name = tftest-wxqfor2xbj
		  organization = redacted
		  region = virginia
		  trusted_ip_ranges.# = 0

and

--- FAIL: TestAccHerokuApp_Space (383.01s)
	testing.go:434: Step 0 error: After applying this step, the plan was not empty:

		DIFF:

		UPDATE: heroku_space.foobar
		  trusted_ip_ranges.#: "1" => "0"
		  trusted_ip_ranges.0: "0.0.0.0/0" => ""

		STATE:

		heroku_app.foobar:
		  ID = tftest-ay1rp1qbdy
		  acm = false
		  all_config_vars.% = 1
		  all_config_vars.FOO = bar
		  config_vars.# = 1
		  config_vars.0.% = 1
		  config_vars.0.FOO = bar
		  git_url = https://git.heroku.com/tftest-ay1rp1qbdy.git
		  heroku_hostname = tftest-ay1rp1qbdy.herokuapp.com
		  name = tftest-ay1rp1qbdy
		  organization.# = 1
		  organization.0.locked = false
		  organization.0.name = redacted
		  organization.0.personal = false
		  region = virginia
		  space = tftest-gpiudrvi2z
		  stack = heroku-16
		  web_url = http://tftest-ay1rp1qbdy.herokuapp.com/

		  Dependencies:
		    heroku_space.foobar
		heroku_space.foobar:
		  ID = 82f6f2d7-cb70-49f4-8bf2-aa69f78bc27e
		  name = tftest-gpiudrvi2z
		  organization = redacted
		  region = virginia
		  trusted_ip_ranges.# = 1
		  trusted_ip_ranges.0 = 0.0.0.0/0

This might be related to #42

Renaming an App breaks many things

Because of the prevalence of using App.Name identifiers throughout the Heroku resources, if an app is renamed after the initial terraform apply, then state may no longer refresh without error.

Here's an example error with the Slug resource after an app rename:

Error: Error refreshing state: 1 error(s) occurred:

• heroku_slug.wasabi: 1 error(s) occurred:

• heroku_slug.wasabi: heroku_slug.wasabi: Error retrieving slug: Get https://api.heroku.com/apps/mars-terra-micro-wasabi-int/slugs/bb8579ca-a052-4fba-9a68-d250b0d115d5: Couldn't find that app.

The config drifts ⛵️☠️

Based on evidence in #93, clearly this is a known challenge.

I checked many of the resources and found two classes of this problem:

1. AppRelease, Formation, TeamCollaborator, & Slug seem to always have this problem
2. AddOn, AppFeature, Cert, Domain, Drain (potentially more) have this problem if they are created using an App Name instead of its UUID.

Possible solution: I'd like to try migrating all the App.Name/AppName usage to App.ID (UUID), but this touches a lot of resources.

Before attempting this, I'd like to hear some feedback from you all about other possible solutions, problems this would cause, or lurking problems of which you might be aware.

terraform refresh does not update heroku_app config_vars

I would expect the heroku_app config_vars to be updated on a terraform refresh, however this does not happen. Currently there is no way to ensure the state is in sync with the current environment variables.

Heroku: Attach addon to multiple apps

This issue was originally opened by @Pluto1010 as hashicorp/terraform#10350. It was migrated here as part of the provider split. The original body of the issue is below.

---

Feature-Request

I'm using Terraform v0.7.13

I think there is a function missing regarding the Heroku provider that enables me to express in a configfile that two apps share one resource.

On Heroku you can attach some existing addons to multiple apps. "heroku addons:attach ...".

I want to use this to make use of a message broker addon. e.G. cloudamqp

provider/heroku: Error on refresh if App is missing

This issue was originally opened by @catsby as hashicorp/terraform#14286. It was migrated here as part of the provider split. The original body of the issue is below.

---

Resource heroku_app seems to throw an error if the App is deleted out of band from Terraform:

• https://github.com/hashicorp/terraform/blob/master/builtin/providers/heroku/resource_heroku_app.go#L348

The Read method (resourceHerokuAppRead) should detect a specific "App no longer exists" type error, remove the app from state with d.SetId(""), and log the removal.

Could also implement an Exists method, like so:

• https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_kms_key.go#L373

Create a resource for outbound rulesets on Heroku Private Spaces

https://devcenter.heroku.com/articles/platform-api-reference#outbound-ruleset

heroku_space_inbound ruleset can't be applied because heroku_space isn't actually ready

terraform -v
Terraform v0.11.8
+ provider.heroku v1.3.0

Affected Resource(s)

• heroku_space
• heroku_space_inbound_ruleset

Terraform Configuration Files

resource "heroku_space" "test_talbright" {
  name         = "test-talbright"
  organization = "${var.organization}"
  region       = "${var.region}"
  shield       = "false"
}

resource "heroku_space_inbound_ruleset" "ruleset" {
  space = "test-talbright"

  rule {
    action = "allow"
    source = "61.120.150.0/28"
  }

  rule {
    action = "allow"
    source = "62.17.146.0/26"
  }
}

Panic Output

heroku_space.test_talbright: Creation complete after 7m28s (ID: a699c0c8-8ac5-4807-8e90-beb0bed77590)

Error: Error applying plan:

1 error(s) occurred:

* heroku_space_inbound_ruleset.ruleset: 1 error(s) occurred:

* heroku_space_inbound_ruleset.ruleset: Error creating inbound ruleset for space (test-talbright): Put https://api.heroku.com/spaces/test-talbright/inbound-ruleset: Couldn't find that space.

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

Expected Behavior

heroku_space_inbound_ruleset resources should have been applied, because the space is ready.

Actual Behavior

heroku_space_inbound_ruleset resources was not applied.

Heroku: DATABASE_URL overwriting

This issue was originally opened by @JeremyLoy as hashicorp/terraform#16631. It was migrated here as a result of the provider split. The original body of the issue is below.

---

See here. Heroku added in 2014 that DATABASE_URL will get automatically set when added on

My Terraform File

resource "heroku_app" "default" {
  name = "terraformpgconfigbug"
  region = "us"
}

resource "heroku_addon" "db" {
  app  = "${heroku_app.default.name}"
  plan = "heroku-postgresql:hobby-dev"
}

Steps to Reproduce

1. terraform plan
2. terraform apply -> should work perfectly fine
3. heroku config - > shows that DATABASE_URL is set automatically
4. terraform plan -> observe DATABASE_URL will be overwritten with "" which is incorrect

Creating multiple apps simultaneously 503

Terraform Version

terraform -v
Terraform v0.11.10
+ provider.heroku (unversioned)
+ provider.random v2.0.0

Heroku Provider Version

master (hashicorp@08f5dba)

Affected Resource(s)

Please list the resources as a list, for example:

• heroku_app

Terraform Configuration Files

resource "heroku_space" "default" {
  name         = "test-terraform-provider-heroku"
  organization = "${var.organization}"
  region       = "${var.region}"
}

resource "random_pet" "default" {}

resource "heroku_app" "default" {
  count  = 10
  name   = "${format("test-app-%d-%s",count.index,random_pet.default.id)}"
  space  = "${heroku_space.default.name}"
  region = "${heroku_space.default.region}"

  organization = {
    name = "${heroku_space.default.organization}"
  }
}

Debug Output

heroku_app.default.8: Still creating... (10s elapsed)
heroku_app.default.9: Still creating... (10s elapsed)
heroku_app.default.1: Still creating... (10s elapsed)
heroku_app.default.2: Still creating... (10s elapsed)
heroku_app.default.7: Still creating... (10s elapsed)
heroku_app.default.0: Still creating... (10s elapsed)
heroku_app.default.5: Still creating... (10s elapsed)
heroku_app.default.3: Still creating... (10s elapsed)
heroku_app.default.4: Still creating... (10s elapsed)
heroku_app.default.6: Still creating... (10s elapsed)
heroku_app.default[7]: Creation complete after 11s (ID: test-app-7-measured-mastodon)
heroku_app.default[1]: Creation complete after 15s (ID: test-app-1-measured-mastodon)
heroku_app.default[9]: Creation complete after 19s (ID: test-app-9-measured-mastodon)
heroku_app.default.5: Still creating... (20s elapsed)
heroku_app.default.2: Still creating... (20s elapsed)
heroku_app.default.0: Still creating... (20s elapsed)
heroku_app.default.8: Still creating... (20s elapsed)
heroku_app.default.6: Still creating... (20s elapsed)
heroku_app.default.3: Still creating... (20s elapsed)
heroku_app.default.4: Still creating... (20s elapsed)
heroku_app.default[8]: Creation complete after 23s (ID: test-app-8-measured-mastodon)
heroku_app.default[0]: Creation complete after 25s (ID: test-app-0-measured-mastodon)
heroku_app.default[4]: Creation complete after 28s (ID: test-app-4-measured-mastodon)
heroku_app.default[6]: Creation complete after 29s (ID: test-app-6-measured-mastodon)
heroku_app.default.5: Still creating... (30s elapsed)
heroku_app.default.2: Still creating... (30s elapsed)
heroku_app.default.3: Still creating... (30s elapsed)
heroku_app.default[3]: Creation complete after 32s (ID: test-app-3-measured-mastodon)
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: 2018/12/23 01:25:22 HTTP/2.0 503 Service Unavailable
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: Content-Length: 561
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: Cache-Control: no-cache, no-store
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: Content-Type: text/html; charset=utf-8
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: Date: Sun, 23 Dec 2018 06:25:22 GMT
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: Via: 2.0 spaces-router (d316c7e8a021)
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: 
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: <!DOCTYPE html>
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: <html>
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:   <head>
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:     <meta name="viewport" content="width=device-width, initial-scale=1">
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:     <meta charset="utf-8">
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:     <title>Application Error</title>
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:     <style media="screen">
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:       html,body,iframe {
2018/12/23 01:25:22 [TRACE] root: eval: *terraform.EvalWriteState
2018/12/23 01:25:22 [TRACE] root: eval: *terraform.EvalApplyProvisioners
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:         margin: 0;
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:         padding: 0;
2018/12/23 01:25:22 [TRACE] root: eval: *terraform.EvalIf
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:       html,body {
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:         height: 100%;
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:         overflow: hidden;
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:       }
2018/12/23 01:25:22 [ERROR] root: eval: *terraform.EvalApplyPost, err: 1 error(s) occurred:

* heroku_app.default.9: Post https://api.heroku.com/teams/apps: encountered an error : 503 Service Unavailable
2018/12/23 01:25:22 [ERROR] root: eval: *terraform.EvalSequence, err: 1 error(s) occurred:

* heroku_app.default.9: Post https://api.heroku.com/teams/apps: encountered an error : 503 Service Unavailable
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku: 
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:       iframe {
2018-12-23T01:25:22.776-0500 [DEBUG] plugin.terraform-provider-heroku:         width: 100%;
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku:         height: 100%;
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku:         border: 0;
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku:       }
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku:     </style>
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku:   </head>
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku:   <body>
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku:     <iframe src="//www.herokucdn.com/error-pages/application-error.html"></iframe>
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku:   </body>
2018-12-23T01:25:22.777-0500 [DEBUG] plugin.terraform-provider-heroku: </html>

Error: Error applying plan:

2 error(s) occurred:

* heroku_app.default[5]: 1 error(s) occurred:

* heroku_app.default.5: Post https://api.heroku.com/teams/apps: encountered an error : 503 Service Unavailable
* heroku_app.default[2]: 1 error(s) occurred:

* heroku_app.default.2: Post https://api.heroku.com/teams/apps: encountered an error : 503 Service Unavailable

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error

Expected Behavior

All ten apps should have been created.

Actual Behavior

Some were created, then received a 503 error from the platform API.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Doesn't send add-on config correctly

Terraform Version

v0.9.11

Affected Resource(s)

• heroku_addon

Terraform Configuration Files

resource "heroku_addon" "postgres" {
  app = "${heroku_app.main.name}"
  plan = "heroku-postgresql:hobby-dev"
  config {
    as = "POSTGRES_URL"
  }
}

Expected Behavior

Should create a database add-on with the environment variable set to POSTGRES_URL.

Actual Behavior

Created the database add-on with the environment variable set to the default of DATABASE_URL. Looking at the state file, it stores this value in config_vars, but if I try to set that value instead of config, I get the error: "config_vars": this field cannot be set.

For reference: https://devcenter.heroku.com/articles/add-ons

Release 0.2.0

Greetings,

There's been awesome progress and development so far. I tried to search details around release cadence and such. Are there plans for when 0.2.0 will come out?

Heroku Pipelines: GitHub Sync is missing

Hello,

to use terraform for heroku it would be useful to configure the github integration within terraform. Currently this is only possible by using the webinterface of heroku.

This would make it possible to have a automatic deployed app after running apply on a new app.

heroku_addon.database: resource repeated multiple times

Hi,
I want to create a pipeline for staging and production apps with separate databases but when I run terraform init I get

Error getting plugins: module root: 1 error(s) occurred:

* heroku_addon.database: resource repeated multiple times

Here is my config file:

# Create Heroku apps for staging and production
resource "heroku_app" "staging" {
  name = "projectapp2-staging"
  region = "eu"
  buildpacks = [
    "heroku/ruby",
    "heroku/nodejs"
  ]
}

resource "heroku_app" "production" {
  name = "projectapp2-production"
  region = "eu"
  buildpacks = [
    "heroku/ruby",
    "heroku/nodejs"
  ]
}

# Create a Heroku pipeline
resource "heroku_pipeline" "projectapp2" {
  name = "projectapp2"
}

# Couple apps to different pipeline stages
resource "heroku_pipeline_coupling" "staging" {
  app      = "${heroku_app.staging.name}"
  pipeline = "${heroku_pipeline.projectapp2.id}"
  stage    = "staging"
}

resource "heroku_pipeline_coupling" "production" {
  app      = "${heroku_app.production.name}"
  pipeline = "${heroku_pipeline.projectapp2.id}"
  stage    = "production"
}

# Create a database, and configure the staging app to use it
resource "heroku_addon" "database" {
  app  = "${heroku_app.staging.name}"
  plan = "heroku-postgresql:hobby-dev"
}

# Create a database, and configure the production app to use it
resource "heroku_addon" "database" {
  app  = "${heroku_app.production.name}"
  plan = "heroku-postgresql:hobby-dev"
}

The database resource is repeated but they have different app names specified.
How do I solve this?

New heroku_space is "dirty" after terraform create

Terraform Version

v0.10.8

Affected Resource(s)

• heroku_space

Terraform Configuration Files

resource "heroku_space" "foobar" {
  name = "foobar-test-space"
  organization = "REDACTED"
  region = "virginia"
}

Debug Output

https://gist.github.com/sheax0r/9ae0667a50e0cf2dc0465022e02c32c9

Expected Behavior

terraform plan immediately after terraform apply should have showed no changes to execute.

Actual Behavior

terraform plan immediately after terraform apply showed that it would result in these changes:

  ~ heroku_space.foobar
      trusted_ip_ranges.#: "1" => "0"
      trusted_ip_ranges.0: "0.0.0.0/0" => ""

Steps to Reproduce

1. Create HCL files as described above.
2. terraform apply
3. terraform plan

Expose heroku_addon config_vars values

I need to extract the value of a configuration variable that a heroku_addon adds to my heroku_app. This is to configure an AWS lambda function that needs to connect to this addon.

However, the config_vars attribute on heroku_addon does not export a map of configuration variables and their values, but only a list of the variables' names.

Here's what a typical config may look like:

resource "heroku_app" "worker" {
  app  = "worker"
}

resource "heroku_addon" "cloudamqp" {
  app  = "${heroku_app.worker.name}"
  plan = "cloudamqp:lemur"
}

output "cloudamqp_config_vars" {
  value = "${heroku_addon.cloudamqp.config_vars}"
}

And the output it gives.

cloudamqp_config_vars = [
    CLOUDAMQP_APIKEY,
    CLOUDAMQP_URL
]

Would it be possible to get a map instead, so I could extract the value I need?