Annotation for: Vendor agnostic build tool information?

loosebazooka commented 5 years ago

We are trying to incorporate more detailed metadata into our builds. Currently there is no standard for build tool information to be surfaced.

Rather that create a vendor specific annotation

"com.loosebazooka.build.tool": "bazookas-docker-builder"

is there any space for the pre-defined annotation keys to include a standard annotation for specifying build tool name (and possibly version)?

Something along the lines of:

org.opencontainers.image.buildtool.name name of the build tool used to create this image/layer (string)
org.opencontainers.image.buildtool.version version of the build tool used to create this image/layer (string)

vbatts commented 5 years ago

so, recording the tool and version that built/assembled the image is interesting, but having it as a pre-defined key is not quite a requirement. Some of these kinds of keys for broader use in the community was one of the goals for https://label-schema.org/rc1/ though it does not look like tool used or its version is any of their prescriptions.

vbatts commented 5 years ago

this would be useful info though. I'm torn.

rajveermalviya commented 4 years ago

Providing a predefined build tool information could be helpful in generalizing all other tools that needs that specific information from images/layers. There are already many implementations of container building tools, so if all the tools start providing their own way to provide version info it could become hard for other tools to keep up with all the custom keys. So, I think it is a better idea to implement annotations in the image spec that can help keeping the workflow generalized.

Podman has already started looking into a custom implementation. So, version-info image annotation is already a requirement for their specific workflow.

https://github.com/containers/buildah/issues/1864

jonjohnsonjr commented 4 years ago

Also torn on this, mildly in favor of it. Especially with the artifacts stuff, I'm not sure if we can rely on the config file to convey this information -- I'm still interested in what version of a tool produced an artifact even if it's not a container image.

FWIW, we've been abusing the "author" field in config history for this within bazel and ko (notably missing version information ☹️):

$ crane config gcr.io/go-containerregistry/crane | jq .
{
  "architecture": "amd64",
  "author": "github.com/google/ko",
  "created": "1970-01-01T00:00:00Z",
  "history": [
    {
      "author": "Bazel",
      "created": "1970-01-01T00:00:00Z",
      "created_by": "bazel build ..."
    },
    {
      "author": "ko",
      "created": "0001-01-01T00:00:00Z",
      "created_by": "ko publish github.com/google/go-containerregistry/cmd/crane",
      "comment": "kodata contents, at $KO_DATA_PATH"
    },
    {
      "author": "ko",
      "created": "0001-01-01T00:00:00Z",
      "created_by": "ko publish github.com/google/go-containerregistry/cmd/crane",
      "comment": "go build output, at /ko-app/crane"
    }
  ],
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": [
      "sha256:0d1435bd79e4253e2c086d5c6340525740f16628bfb80aa95b333f983bbf537d",
      "sha256:4f76c7cc15474e09ddbebb4b39759df491cde9af6c85700612e7ec756492d571",
      "sha256:6e154429956d5820536fbc899abdd42ca42fe9218340f627b74ec311a9092321"
    ]
  },
  "config": {
    "Entrypoint": [
      "/ko-app/crane"
    ],
    "Env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
      "SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt",
      "KO_DATA_PATH=/var/run/ko"
    ]
  }
}

That is a ko-produced image with a distroless base image, which was built with bazelbuild/rules_docker.

A more structured way to do this would be really nice if e.g. you want to reproduce a bug and need to determine which version of a build tool produced the image.

loosebazooka commented 4 years ago

A more structured way to do this would be really nice if e.g. you want to reproduce a bug and need to determine which version of a build tool produced the image.

We might need to include some other metadata in this case? Repository, commit id, base image id?

dn-scribe commented 4 months ago

Hope it is ok to wake up this dormant issue; I would like to suggest having annotations for the build service:

URL to workflow or pipeline (this should work for most build systems). Such a URL conveys also the build system\service in use
pipeline run id.

Use case: Something went wrong (quality or security) and I want to investigate it; a link to the build information would enable me to examine the logs and pipeline settings. The build adds many parts to the final image: dependencies, configurations, data migrations, authentication information (certificates), and more. Usually the pipeline run logs would include the checked-out code hash, so that is not critical.

opencontainers / image-spec

Annotation for: Vendor agnostic build tool information? #748