Description
ko
-built images contain Go-built binaries, which embed build information like what commit the binary was built at (which is good!). However, this means that terraform plans that include ko
-built images also emit diffs when the commit changes (this is less good).
For example, git rebase
ing some code and terraform plan
ning shows this:
# google_cloud_run_service.blah will be updated in-place
~ resource "google_cloud_run_service" "blah" {
# (4 unchanged attributes hidden)
~ template {
~ spec {
# (3 unchanged attributes hidden)
~ containers {
~ image = "gcr.io/blah/github.com/foo/bar@sha256:c2ee0f6616733dae3305b998e5816745b33d5ccc2c9aaa5da4b1dc89bb21b4d80" -> (known after apply)
# (2 unchanged attributes hidden)
# (3 unchanged blocks hidden)
}
}
# (1 unchanged block hidden)
}
# (2 unchanged blocks hidden)
}
# ko_image.redirect will be created
+ resource "ko_image" "image" {
+ base_image = "gcr.io/distroless/static:nonroot"
+ id = (known after apply)
+ image_ref = (known after apply)
+ importpath = "github.com/foo/bar"
+ platforms = "linux/amd64"
+ working_dir = "."
}
This isn't terribly helpful, since I don't know if apply
ing this change will roll out massive breaking code changes or just tiny things picked up by the rebase.
I wonder if there's any way to better express the code/image diff that this Terraform diff is communicating. I don't want a full git diff
between the commits (or maybe I do?), but if there was way to print a summary of changes that could be cool.
Practically speaking, maybe the ko_image
resource could have a field for the corresponding embedded Go binary build information (e.g., vcs.revision
), which would show up in the lower section.
This would probably mean we need ko_image
s to be "updated" instead of "created" each time, and I'm not sure if that's a bad idea for some reason. We'd also need to do a ko
build(+publish?) before we'd be able to surface that diff, so we don't just see (known after apply)
. That makes terraform plan
ning slower, but hopefully not too slow.
This is mostly a tracking issue to gather ideas and find out what's (im)possible.