Idea: better diff summaries for ko_image changes

[imjasonh]

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 rebaseing some code and terraform planning 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 applying 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_images 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 planning slower, but hopefully not too slow.

This is mostly a tracking issue to gather ideas and find out what's (im)possible.