Deployments: investigate support build and push settings

[mitchnielsen]

Summary

Let's investigate supporting the build and push settings in the Deployment resource in our provider.

Acceptance criteria

• If build settings can work and make sense in the provider, create an issue for supporting them
• If push settings can work and make sense in the provider, create an issue for supporting them

[rh-km]

@mitchnielsen - thanks for getting this ticket together, and for your work to date on the prefect provider. So far it has been smooth sailing to work with. We are evaluating prefect and scoping out how we want to do our deployments. Basically all of our other systems deploy through terraform (technically speaking it is CDKTF) so there would be some benefit for us to have everything that way (including flow deploys which are currently using the yaml deploy in our proof of concept).

After looking at the deployment stuff a bit more, I certainly see a way forward without having the build and push settings being supported. I would also sort of buy the argument that it might not make sense for the prefect provider / deployment resource to have those responsibilities. For our use case (AWS ECS repo for the image), it should all be doable by pulling in the AWS provider and the Docker provider. Something like

resource "aws_ecr_repository" "repo" {
  name                 = "repo"
  image_tag_mutability = "MUTABLE"

  image_scanning_configuration {
    scan_on_push = true
  }
}

resource "docker_image" "my_flow" {
  name = "000000000000.dkr.ecr.us-west-2.amazonaws.com/repo/my-flow"
  build {
    context = "."
    tag     = ["my-flow:latest"]
  }
}

When you define the flow, you can reference the docker_image object's name for the image in the job_variables

[mitchnielsen]

thanks for getting this ticket together, and for your work to date on the prefect provider. So far it has been smooth sailing to work with.

Cheers, thanks, that's great to hear 🤝

After looking at the deployment stuff a bit more, I certainly see a way forward without having the build and push settings being supported. I would also sort of buy the argument that it might not make sense for the prefect provider / deployment resource to have those responsibilities. For our use case (AWS ECS repo for the image), it should all be doable by pulling in the AWS provider and the Docker provider. When you define the flow, you can reference the docker_image object's name for the image in the job_variables

That's good context to have, thanks - when we kick this off I'd like to set up a functional example using config similar to that and make sure it works. If we don't directly add build/push to the provider here, then I think it makes sense to at least document one or two common alternative patterns to follow.