Many apps deployed to Heroku require that multiple buildpacks be
configured in a particular order to operate correctly.
This updates the builtin Heroku provider's app resource to support
configuring buildpacks and the related documentation in the website.
Similar to config vars, externally set buildpacks will not be altered if
the config is not set.
It seems there are 4 locations left that use the `helper/multierror`
package, where the rest is TF settled on the `hashicorp/go-multierror`
package.
Functionally this doesn’t change anything, so I suggest to delete the
builtin version as it can only cause confusion (both packages have the
same name, but are still different types according to Go’s type system.
Fixes the following vet reports:
builtin/providers/heroku/resource_heroku_app.go:192: arg vs for printf verb %s of wrong type: bool
builtin/providers/heroku/resource_heroku_app.go:198: arg vs for printf verb %s of wrong type: bool
Before all providers were using the helper.Schema approach the helper
function had these names. Now they all use names consistent with the Go
naming conventions except for these last few…
cc/ @catsby if you're curious. That fixed the acceptance tests,
thought there is still one (different issue) that is still failing.
Also, it nows construct a transport instead of using the default
and setting the auth globally. TF could potentially run things
concurrently and that might go wrong.
Bernerd Schaefer