terraform-provider-heroku
terraform-provider-heroku copied to clipboard
Consistent use of ReviewApp resource
I have hard time enabling reviewApp config through terraform
The first time I run terraform apply, the pipeline is created, but the reviewApp api call do not include the new pipelineid
Error: Unable to retrieve review apps config for pipeline <id_should_be_there?>
Get "https://api.heroku.com/pipelines/<id_should_be_there?>/review-app-config"
The second time, if I enable reviewApp manually (connect to github) and run terraform apply, I get
Error: Unable to enable review apps config for pipeline 09b59d7d-bf14-437e-8119-fab08d898ab4
Post "https://api.heroku.com/pipelines/09b59d7d-bf14-437e-8119-fab08d898ab4/review-app-config"
Review Apps is already enabled for this pipeline
Is there a way to make it work no matter if the pipeline has been connected to github ? It's ok to have a manual step to connect github to heroku, but terraform apply should be consistent
Version
Terraform v0.14.11 -> v1.1.3
provider.heroku v4.8.0
Affected Resource(s)
- heroku_review_app_config
- heroku_pipeline
Terraform Configuration Files
resource "heroku_pipeline" "test-pipeline" {
name = "test-pipeline"
...
}
data "heroku_pipeline" "test-pipeline" {
name = "test-pipeline"
}
resource "heroku_review_app_config" "foobar" {
pipeline_id = data.heroku_pipeline.test-pipeline.id
...
}
Expected Behavior
At least, apply the plan and configure reviewApp But, leave the connection step github <-> heroku manual
Actual Behavior
Errors depending on the state of reviewApp integration
Steps to Reproduce
terraform apply
Hi @romainPrignon,
The reason the Pipeline ID is missing on the initial apply, is because the example config is using a data source to get the pipeline's ID. When a resource is created in a config, its ID should be used directly, like this modified example:
resource "heroku_review_app_config" "foobar" {
pipeline_id = heroku_pipeline.test-pipeline.id
...
}
Data sources only fetch new data once early in the apply process, so they do not see new resources until the next apply.
General rule
Resource created in the config β use the resource's attributes.
Resource already exists outside config β use a data source to retrieve attributes.
Hi @mars :) Thanks for the explanation. But I did try using the pipeline id as well before using a datasource and the result is the same :( I can't find a way to create a pipeline and link it to a prAppSettings in the same apply :(
Sorry for misleading you @romainPrignon. Looking deeper into this, I am reminded that Pipelines API is limited, and apparently it cannot be usefully Terraformed from scratch.
Best practice will be to manually setup up a Pipeline (configuring the GitHub repository integration & enabling Review Apps) and then Review Apps could be Terraformed using the Pipeline data source.
oh :( That's exactly what I'm trying to terraform to prevent manual intervention each time there's a new app I understand why the github <-> heroku connection needs to be manual. But it would be great to terraform pipeline and review app config (not the connection with github) so it can be versionned
Thanks for your help ! I'll try to find a way with a custom script I guess
I agree, but cannot fix this issue without Heroku API itself making more of these features available. π Thanks for opening this issue, and for your understanding.
I'm not entirely sure if this will help your usecase but my herokux provider has this resource: https://registry.terraform.io/providers/davidji99/herokux/latest/docs/resources/pipeline_github_integration.
FYI herokux is separate from heroku.
Thanks @davidji99. I'll git it a try today. But what I understand when I read the given example is that I still need 2 separate PR (or 2 apply) to make it work :/ I'm trying to make a module that abstract a Heroku Project (pipeline, reviewapp, addons, features) so that devs can use it to bootstrap their new project
It should be one apply assuming you have a service user doing the applys in Heroku. That way, you only need to do github to heroku authorization once.
On Tue, Jan 25, 2022 at 15:58 Romain Prignon @.***> wrote:
Thanks @davidji99 https://github.com/davidji99. I'll git it a try today. But what I understand when I read the given example is that I still need 2 separate PR (or 2 apply) to make it work :/ I'm trying to make a module that abstract a Heroku Project (pipeline, reviewapp, addons, features) so that devs can use it to bootstrap their new project
β Reply to this email directly, view it on GitHub https://github.com/heroku/terraform-provider-heroku/issues/327#issuecomment-1020867780, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6OTJ3BUWQSK4YCOZ3QMG3UXZCYJANCNFSM5MJ44RRA . You are receiving this because you were mentioned.Message ID: @.***>
--
- David
I'm not entirely sure if this will help your usecase but my
herokuxprovider has this resource: https://registry.terraform.io/providers/davidji99/herokux/latest/docs/resources/pipeline_github_integration.FYI
herokuxis separate fromheroku.
Or, you could use app.json file in the root of your appβs GitHub repo for review apps to work.
Or, you could use app.json file in the root of your appβs GitHub repo for review apps to work.
Well, I just tried it, and it doesn't work! My new Heroku app includes app.json with all app and add-on details, but it does not use it to provide add-ons or app config.
Speaking of config:
if I start with fresh Terraform state, I can not use heroku_pipeline_config_var in order to terraform configs for review apps too?!
For example, I have a resource heroku_config with sensitive_vars:
# heroku/eva/configs.tf
resource "heroku_config" "common" {
vars = {
# ...
}
sensitive_vars = {
# This key is used to decrypt credentials (and other encrypted files).
RAILS_MASTER_KEY = var.RAILS_MASTER_KEY
}
}
And I need this master key in review apps too, and I would like to provide it over heroku_pipeline_config_var, which needs pipeline_id. So, I have to do something like this:
# heroku/eva/pipelines.tf
# define a team pipeline
resource "heroku_pipeline" "pipeline" {
name = "${var.app_prefix}-${var.app_name}-pipeline"
owner {
id = data.heroku_team.<team_name>.id
type = data.heroku_team.<team_name>.type
}
}
# heroku/eva/configs.tf
# Associate web app with config vars
data "heroku_pipeline" "pipeline" {
name = "${var.app_prefix}-${var.app_name}-pipeline"
}
resource "heroku_pipeline_config_var" "review" {
pipeline_id = heroku_pipeline.pipeline.id
pipeline_stage = "review"
vars = heroku_config.common.vars
sensitive_vars = heroku_config.common.sensitive_vars
}
But, with fresh state, there is no heroku_pipeline at all. So, I get this error:
β Error: Get "https://api.heroku.com/pipelines/<app_prefix-app_name>-pipeline": Not found.
β
β with module.heroku.module.eva.data.heroku_pipeline.pipeline,
β on heroku/eva/configs.tf line 24, in data "heroku_pipeline" "pipeline":
β 24: data "heroku_pipeline" "pipeline" {
As you can see, I use module heroku and eva (app name), but that doesn't matter here.
I'm new to Terraform and after 2 days I have no idea how to provision Heroku review apps with Terraform.
I can use and provision Heroku pipeline, but without heroku_pipeline_config_var and heroku_review_app_config. And I still do not see any advantages of using Terraform?!
Review Apps in a Pipeline are designed to work through Heroku's web dashboard, driven by events from the connected GitHub repo. Using Terraform for this may not be worth the trouble or ever solve your problems.
Let's step back a moment to ask: what is your goal @viktorianer? Can Heroku's built-in Review Apps experience serve that purpose? Since Review Apps are an ephemeral development experience, what are you trying to gain by using Terraform?
To assert my conclusion more directly:
- use Terraform to create & manage your long-lived staging/production resources
- use Heroku's built-in developer experience (Pipelines + Review Apps) to create & manage the ephemeral development resources
- these two strategies do not intersect gracefully, either go full Terraform or full Pipelines.
@mars Thank for your advice. It is what I'm actually going to do now. And use Heroku CLI first, then adding some automation to GitHub. I will see.
What I first thought, is to use Terraform to create all resources for all stages, including Heroku review apps.
Because, if I connect my pipeline, created with Terraform, to GitHub through Heroku's web dashboard, then for review apps there is no app config, non environments, none of add-ons the app needs to run. The apps created for PRs are not working.
In my case, I tried to add app.json, in order to set up Review Apps as described here. However, this file does not change anything. I am not sure why.
Therefore, Terraform Heroku is useless for development and review stage, because I can not set up CD, including Release Phase.
Or, how do I use Heroku CD, described here, with Terraform?
But I would be happy to create Review Apps with all add-ons, etc., so that they are running.
You cannot just use Heroku CD with Terraform. There is no provision by Heroku for Terraform intersecting with the built-in developer experience.
Either pick Heroku CD, or develop everything using Terraform.
Re: app.json, that is only used by Heroku when first creating the review app. It has no relation to Terraform.
Hi @mars @romainPrignon,
It seems the heroku_review_app_config resource stopped working properly in heroku/provider version 4.7.0 because heroku/go package was upgraded from version 5.3.0 to 5.4.0. I opened an issue regarding to this some time ago here but I didn't get any response.
@amatellanes please upgrade to the most recent Heroku provider version, v5.1.1, and let us know if this is still an issue. Note that upgrading from v4 to v5 will require some manual config changes; see the Upgrading Guide.
Also, I commented on the linked heroku-go issue, questioning why this is actually a problem.
Hi @mars,
Many thanks for replying my comment.
I've just tested the new Heroku Terraform Provider v5.1.2 to check if heroku_review_app_config resource works properly. I've been following the official documentation to configure review apps in Heroku using Terraform here.
These are the steps I followed:
- I've created the pipeline manually and connected to a GitHub repo as documentation suggests.
- Then I run this simple configuration to check that the
heroku_pipelinedata source works:
data "heroku_pipeline" "test-pipeline" {
name = "test-pipeline"
}
I got error:
β·
β Error: Get "https://api.heroku.com/pipelines/test-pipeline": Not found.
β
β with data.heroku_pipeline.test-pipeline,
β on main.tf line 17, in data "heroku_pipeline" "test-pipeline":
β 17: data "heroku_pipeline" "test-pipeline" {
β
β΅
Operation failed: failed running terraform plan (exit 1)
-
After checking
heroku_pipelinedata source documentation here, I realized that I needed to create and add an app to the pipeline manually -
The
terraform planworks :ok_hand: -
I tried to configure review apps with the documentation example:
resource "heroku_review_app_config" "foobar" {
pipeline_id = data.heroku_pipeline.test-pipeline.id
org_repo = "yourcompany/yourrepo"
automatic_review_apps = true
base_name = "yourcompany"
deploy_target {
id = "us"
type = "region"
}
destroy_stale_apps = true
stale_days = 5
wait_for_ci = true
}
I got this error:
β Error: Unable to enable review apps config for pipeline 59afc28e-a35f-4579-be3e-d231a4627d5f
β
β with heroku_review_app_config.foobar,
β on main.tf line 26, in resource "heroku_review_app_config" "foobar":
β 26: resource "heroku_review_app_config" "foobar" {
β
β Post
β "https://api.heroku.com/pipelines/59afc28e-a35f-4579-be3e-d231a4627d5f/review-app-config":
β Something went wrong, Review Apps was not enabled for this pipeline.
β΅
Operation failed: failed running terraform apply (exit 1)
- Additionally I tried to configure the review apps but only using the required field according to official documentation:
resource "heroku_review_app_config" "foobar" {
pipeline_id = data.heroku_pipeline.test-pipeline.id
org_repo = "yourcompany/yourrepo"
deploy_target {
id = "us"
type = "region"
}
}
After applying the changes, the review apps was enabled but I got this error:
β Error: Unable to retrieve review apps config for pipeline
β
β with heroku_review_app_config.foobar,
β on main.tf line 26, in resource "heroku_review_app_config" "foobar":
β 26: resource "heroku_review_app_config" "foobar" {
β
β Get "https://api.heroku.com/pipelines//review-app-config": The requested
β API endpoint was not found. Are you using the right HTTP verb (i.e. `GET`
β vs. `POST`), and did you specify your intended version with the `Accept`
β header?
I tried to apply changes again but I got an expected error since the review app was enabled:
β Error: Unable to enable review apps config for pipeline 59afc28e-a35f-4579-be3e-d231a4627d5f
β
β with heroku_review_app_config.foobar,
β on main.tf line 26, in resource "heroku_review_app_config" "foobar":
β 26: resource "heroku_review_app_config" "foobar" {
β
β Post
β "https://api.heroku.com/pipelines/59afc28e-a35f-4579-be3e-d231a4627d5f/review-app-config":
β Review Apps is already enabled for this pipeline.
β΅
Operation failed: failed running terraform apply (exit 1)
If I didn't do anything wrong in my example, I would say that heroku_review_app_config resource seems not to be very consistent.
Hello,
I'm having a similar issue trying to manage my review apps with Terraform (after successfully importing staging and production stages into TF).
First of all, my files look like this:
data "heroku_pipeline" "api" {
name = var.app_name
}
The pipeline having been created by a different/previous TF run, I know this data source works as I'm using it for my staging & production runs also (and I can see the ID in the messages you read just before).
resource "heroku_pipeline_config_var" "configs" {
pipeline_id = data.heroku_pipeline.api.id
pipeline_stage = "review"
vars { /* my vars */ }
sensitive_vars { /* my sensitive vars */ }
}
resource "heroku_review_app_config" "api" {
pipeline_id = data.heroku_pipeline.api.id
org_repo = "${var.team_name}/${var.app_name}"
automatic_review_apps = true
base_name = var.app_name
deploy_target {
type = "region"
id = "eu"
}
destroy_stale_apps = true
stale_days = 14
wait_for_ci = true
}
Now, when I plan my changes, I get something like this:
# heroku_pipeline_config_var.configs will be updated in-place
~ resource "heroku_pipeline_config_var" "configs" {
id = "<my_pipeline_id>:review"
# (5 unchanged attributes hidden)
}
# heroku_review_app_config.api must be replaced
-/+ resource "heroku_review_app_config" "api" {
~ id = "<my_pipeline_id>" -> (known after apply)
+ pipeline_id = "<my_pipeline_id>" # forces replacement
~ repo_id = <some_repo_id> -> (known after apply)
# (6 unchanged attributes hidden)
# (1 unchanged block hidden)
}
β οΈ What catches my attention is the fact that the plan wants to update the id of the heroku_review_app_config even though I can't set it in my Terraform files (and I don't know what the new value will be even though the old one is the ID of the pipeline), but is also wants to create the pipeline_id property when it should already be populated by the import I did?
And when I apply, this error happens:
Error: Unable to retrieve review apps config for pipeline
β
β with heroku_review_app_config.api,
β on review-app-config.tf line 1, in resource "heroku_review_app_config" "api":
β 1: resource "heroku_review_app_config" "api" {
β
β Get "https://api.heroku.com/pipelines//review-app-config": The requested API endpoint was not found.
β Are you using the right HTTP verb (i.e. `GET` vs. `POST`), and did you specify your intended version
β with the `Accept` header?
And if I run this again, the plan wants to create the review_app_config all over again:
# heroku_pipeline_config_var.configs will be updated in-place
~ resource "heroku_pipeline_config_var" "configs" {
id = "<my_pipeline_id>:review"
# (5 unchanged attributes hidden)
}
# heroku_review_app_config.api will be created
+ resource "heroku_review_app_config" "api" {
+ automatic_review_apps = true
+ base_name = "my-api"
+ destroy_stale_apps = true
+ id = (known after apply)
+ org_repo = "mycompany/myreponame"
+ pipeline_id = "<my_pipeline_id>"
+ repo_id = (known after apply)
+ stale_days = 14
+ wait_for_ci = true
+ deploy_target {
+ id = "eu"
+ type = "region"
}
}
Which of course fails:
β Error: Unable to enable review apps config for pipeline <my_pipeline_id>
β
β with heroku_review_app_config.api,
β on review-app-config.tf line 1, in resource "heroku_review_app_config" "api":
β 1: resource "heroku_review_app_config" "api" {
β
β Post "https://api.heroku.com/pipelines/<my_pipeline_id>/review-app-config":
β Review Apps is already enabled for this pipeline.
And this process manages to destroy the review apps already running somehow�
Sorry to be pushy on this, but seeing how it can break our deployment, is there any update on this issue?
Did you manage to find the cause for this behavior? I tried updating to the new provider version (5.1.3) but didn't notice any change with review apps.
Please, see the [updated] explanation on #343. Hopeful it resolves this issue π
CI is failing on some unrelated error, but in the meantime I released v5.1.4-pre1 to allow y'all to go ahead and try it out. It should be available in the registry within an hour.
Here's configuration to use it:
terraform {
required_providers {
heroku = {
source = "heroku/heroku"
version = "5.1.4-pre1"
}
}
}
provider "heroku" {
# Configuration options
}
The heroku_review_app_config works much better, thanks!
I still have one small issue (not sure if related though).
I keep seeing the following change on plan/apply, even after applying the change.
Terraform used the selected providers to generate the following execution plan. Resource actions are
indicated with the following symbols:
~ update in-place
Terraform will perform the following actions:
# heroku_pipeline_config_var.api will be updated in-place
~ resource "heroku_pipeline_config_var" "api" {
id = "<some-uuid>:review"
# (5 unchanged attributes hidden)
}
It doesn't seem to break anything, the review apps still run and config vars are correct, but this remains in the TF plan every timeβ¦
Great to hear @viki53!
My guess about heroku_pipeline_config_var being changed in-place, is that perhaps one or more of the vars are populated by a dynamic value that is not known until apply. I cannot reproduce any issues with that resource, so it seems this is expected behavior based on your specific Terraform configuration. I've definitely seen dynamically calculated config vars on apps cause in-place updates in some configurations.
I released v5.1.4 with this fix. It should be published to the registry within an hour.