Provides a Heroku Build resource, to deploy source code to a Heroku app.
Either a URL or local path, pointing to a tarball of the source code, may be deployed. If a local path is used, it may instead point to a directory of source code, which will be tarballed automatically and then deployed.
This resource waits until the build & release completes.
If the build fails, the build log will be output in the error message.
To start the app from a successful build, use a Formation resource to specify the process, dyno size, and dyno quantity.
The code contained in the source directory or tarball must follow the layout required by the buildpack
or the Dockerfile
for container builds.
This is the default build process.
For apps that do not have a buildpack set, the official Heroku buildpacks will be searched until a match is detected and used to compile the app.
A Procfile
may be required to successfully launch the app.
Some buildpacks provide a default web process, such as npm start
for Node.js.
Other buildpacks may require a Procfile
, like for a pure Ruby app.
To use container builds, set the parent heroku_app
resource's stack = "container"
A heroku.yml
manifest
file is required to declare which Dockerfile
to build for each process. Be careful not to create conflicting configuration
between heroku.yml
and Terraform, such as addons or config vars.
A source.url
may point to any https://
URL that responds to a GET
with a tarball source code. When running terraform apply
,
the source code will only be fetched once for a successful build. Change the URL to force a new resource.
💡 Useful for building public, open-source source code, such as projects that publish releases on GitHub.
â›” Not useful for private URLs that require credentials to access.
GitHub provides release tarballs through URLs. Create a release
and then use the tag as a source.url
, such as:
https://github.com/username/example/archive/v1.0.0.tar.gz
Using a branch or master source.url
is possible, but be aware that tracking down exactly what commit was deployed
for a given terraform apply
may be difficult. On the other hand, using stable release tags ensures repeatability
of the Terraform configuration.
resource "heroku_app" "foobar" {
name = "foobar"
region = "us"
}
resource "heroku_build" "foobar" {
app_id = heroku_app.foobar.id
buildpacks = ["https://github.com/mars/create-react-app-buildpack"]
source {
# This app uses a community buildpack, set it in `buildpacks` above.
url = "https://github.com/mars/cra-example-app/archive/v2.1.1.tar.gz"
version = "v2.1.1"
}
}
resource "heroku_formation" "foobar" {
app_id = heroku_app.foobar.id
type = "web"
quantity = 1
size = "Standard-1x"
depends_on = ["heroku_build.foobar"]
}
A source.path
may point to either:
src/appname
relative paths to subdirectories within the Terraform project repo (recommended)/opt/src/appname
absolute or ../appname
relative paths to external directories../
will cause errors during applyWhen running terraform apply
, if the contents (SHA256) of the source path changed since the last apply
, then a new build will start.
🚚 The complete source must already be present at its path
when Terraform runs, so either:
path
before Terraform runs, like this issue's solutionresource "heroku_app" "foobar" {
name = "foobar"
region = "us"
}
resource "heroku_build" "foobar" {
app_id = heroku_app.foobar.id
source {
# A local directory, changing its contents will
# force a new build during `terraform apply`
path = "src/example-app"
}
}
resource "heroku_formation" "foobar" {
app_id = heroku_app.foobar.id
type = "web"
quantity = 1
size = "Standard-1x"
depends_on = ["heroku_build.foobar"]
}
The following arguments are supported:
app_id
- (Required) Heroku app ID (do not use app name)buildpacks
- List of buildpack GitHub URLssource
- (Required) A block that specifies the source code to build & release:
checksum
- SHA256 hash of the tarball archive to verify its integrity, example:
SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
path
- (Required unless source.url
is set) Local path to the source directory or tarball archive for the appurl
- (Required unless source.path
is set) https
location of the source archive for the appversion
- Use to track what version of your source originated this build. If you are creating builds
from git-versioned source code, for example, the commit hash, or release tag would be a good value to use for the
version parameter.The following attributes are exported:
uuid
- The ID of the buildoutput_stream_url
- URL that streams the log output from the buildrelease_id
- The Heroku app release created with a build's slugslug_id
- The Heroku slug created by a buildstack
- Name or ID of the Heroku stackstatus
- The status of a build. Possible values are pending
, successful
and failed
user
- Heroku account that created a build
email
id
Existing builds can be imported using the combination of the application name, a colon, and the build ID.
For example:
$ terraform import heroku_build.foobar bazbux:4f1db8ef-ed5c-4c42-a3d6-3c28262d5abc
foobar
is the heroku_build resource's namebazbux
is the Heroku app name (or ID) that the build belongs to:
separates the app identifier & the build identifier4f1db8ef…
is the build ID