Skip to content

Idea: better diff summaries for ko_image changes #27

Open
@imjasonh

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions