Mars Hall

@levivm then, perform that download before running Terraform, so that the source code is already at a consistent `source.path`.

The options here are: `source.url`, a public URL. `source.path`, can come from anywhere, anyhow, but it needs to be in-place before running Terraform. If either `source.url` or `source.path` change, then...

`null_resource` tricks might work to run a provisioner to fetch the source ahead of time, but be aware that `null_resource` has some really stupid behavior. Once `null_resource` is created, it...

When this `heroku_build` / `source.path` feature was implemented, the expectation was that the source code for `heroku_build` is included along with the Terraform configuration, as subdirectories of the Terraform configuration...

I've read through all these interlinked issues & PRs, and do not see how this can be merged, because: * the `heroku_addon` attachment name cannot be read nor confidently inferred...

## Workaround 🧰 When an add-on attachment name is required for your use-case, create a new `heroku_app` (just to host the add-on) and on that app a `heroku_addon`. Then, create...

Note that config vars set by attached Heroku Addons should be ignored from Terraform state. They change dynamically (such as periodic Postgres credential rotation). IMO Inverting the ownership of their...

Agreed @shawncatz , in the proposal I intentionally avoid parsing URLs in Terraform. Just because a value is a valid URI does not mean it's valid for a buildpack. By...

Understandable @shawncatz , I'm to putting this in my queue to work on in the next few weeks 📥

I've been working on implementing this, but I've found it's blocked by the behavior of the Platform API. Specifically, when setting a buildpack by `Name`, API accepts it, but **then...