Using app action 2.x.x with Terraform

[razum90]

Hi!

I am looking to upgrade the app action from 1.1.6 -> 2.0.1. As of now, my app spec is done with terraform. In my CI/CD pipeline I am just deploying new versions of the service, the building of new versions happens in GitHub actions.

1. Does the app action yaml spec in my repo override what I already have defined through terraform? Or can this yaml spec be used together with my terraform spec? Otherwise, I guess I would have to rewrite my entire terraform config to this new yaml app spec instead.

2. Depending on the above question, I need to understand whether I can choose to not use the yaml app spec and keep using terraform, while just deploying a new docker image somehow from my GitHub actions as I am doing today.

BR

[markusthoemmes]

If you're using terraform, I assume that that's used to update the app spec's state inside App Platform? If so, then yeah, the action is sort of redundant to that as it'll do the very same thing but based on the "native" YAML spec format. There's no reason for you to switch if what you have works for you.

Wrt. to the image upgrades, see https://github.com/digitalocean/app_action?tab=readme-ov-file#updating-images. The "old" way of updating an app in-place remains intact by using the app_name input. The way of specifying the image "overrides" has changed though, as documented there.

[markusthoemmes]

@razum90 does this answer your question?

[razum90]

Hi @markusthoemmes, sorry for the late answer.

Do I still need the yaml spec to specify the docker registry?

Another thing is that I have a monorepo setup, so I am reusing GitHub Actions for different deplyables in the same DO app. It works fine with the current version because the images field can be set dynamically. With an environment variable it seems harder. I need to figure out how to handle that.

[markusthoemmes]

The docker registry can be specified in the app itself (if you're using app_name to update an existing app) or the YAML app spec (if you're using app_spec_location).

You can no longer change the registry "on-the-fly" via the images input. The new environment variables only allow you to override either tag or digest, assuming that the registry type, registry and repository would remain the same.

Do you need to update one of those 3 fields dynamically? If so: Why?

[razum90]

All right. So the registry I will have to modify using terraform, in case I would ever want to change it. I think that's ok, although I would prefer to specify it in my GitHub action to completely control it from one place.

I have a reusable deploy GitHub action (reusable meaning that I have different components in the same DO app that can be separately deployed). So I need the IMAGE_TAG_<component-name> to be dynamic. I.e. I want to specify the image tag of the component name I want to deploy. I assume that the rest of the components keep their current tag in this case. Do you understand what I mean?

[markusthoemmes]

Yep, that's how it works. I sort of understand the "wanting to control things from one place" argument here, but I'd say that's where I'd recommend moving the entirety of the spec handling into a Github Action, i.e. run terraform as part of your GHA or move to an in-repo YAML-based spec.

Wrt. the image references: Yep, all other components would remain on their current tag, like in the v1 version as well.

[markusthoemmes]

@razum90 looping back to this, are your questions answered here?

[markusthoemmes]

Going to close this for now. @razum90 feel free to poke again if this is still an issue.

[razum90]

Yes thanks @markusthoemmes my questions are answered, sorry for the late response.