Update image info schema to have image/platform concepts

[mthalman]

In order to support data like shared tags in the image info file, the schema needs to be updated to group Dockerfiles associated with a single manifest tag just as the manifest does. This grouping is referred to as an image while each of the underlying items are referred to as a platform. I've updated the schema to reflect this by renaming the previously named ImageData to PlatformData because that is really what it represents now and introducing a new ImageData class that groups the PlatformData instances.

OLD schema example:

[
  {
    "repo": "repo2",
    "images": [
      {
        "1.0/repo2/os1/Dockerfile": {
          "simpleTags": [
            "tag1"
          ],
        },
        "1.0/repo2/os2/Dockerfile": {
          "simpleTags": [
            "tag2"
          ],
        }
      }
    ]
  }
]

NEW schema example:

[
  {
    "repo": "repo2",
    "images": [
      {
        "platforms": {
          "1.0/repo2/os1/Dockerfile": {
            "simpleTags": [
              "tag1"
            ]
          }
        }
      },
      {
        "platforms": {
          "1.0/repo2/os2/Dockerfile": {
            "simpleTags": [
              "tag2"
            ]
          }
        }
      }
    ]
  }
]

The main impact this change causes is with the merging behavior. There needs to be a way to determine which image instance a platform belongs when merging a source to a target. The image has no identifying data. This is accomplished by correlating in memory each image in an image info file with its related image in the manifest file. That can then be used as a reference identifier to pair up related images between two separate image info files.

Fixes #286

[MichaelSimons]

The proposed schema makes me think there is an existing issue with the current schema that is not addressed with the new schema. That is using the Dockerfile path as the key to the image/platform Dictionary is an issue. Specially in the case of the samples where we build the same Dockerfile multiple time - https://github.com/dotnet/versions/blob/master/build-info/docker/image-info.dotnet-dotnet-docker-master.json#L1477. To address this, should the image collection be an array and the Dockerfile be an attribute of the platform?

[MichaelSimons]

#286 tracks the Dockerfile path issue I previously mentioned. I think we should be addressing this problem with this schema change.

[mthalman]

The proposed schema makes me think there is an existing issue with the current schema that is not addressed with the new schema. That is using the Dockerfile path as the key to the image/platform Dictionary is an issue. Specially in the case of the samples where we build the same Dockerfile multiple time - https://github.com/dotnet/versions/blob/master/build-info/docker/image-info.dotnet-dotnet-docker-master.json#L1477. To address this, should the image collection be an array and the Dockerfile be an attribute of the platform?

Yes, I've made that change. This required adding some more data to the PlatformData class to allow a given instance to be distinguishable from another that has the same Dockerfile path. So the distinguishing data of a platform is Dockerfile path, architecture, OS type, and OS version.

The schema will now look like this:

[
  {
    "repo": "repo2",
    "images": [
      {
        "platforms": [
          {
            "path": "1.0/repo2/os1/Dockerfile",
            "architecture": "arm64",
            "osType": "Linux",
            "osVersion": "Ubuntu 18.04",
            "simpleTags": [
              "tag1"
            ]
          },
          {
            "path": "1.0/repo2/os1/Dockerfile",
            "architecture": "arm",
            "osType": "Linux",
            "osVersion": "Ubuntu 18.04",
            "simpleTags": [
              "tag1"
            ]
          }
        ]
      },
      {
        "platforms": [
          {
            "path": "1.0/repo2/os2/Dockerfile",
            "architecture": "amd64",
            "osType": "Linux",
            "osVersion": "Ubuntu 18.04",
            "simpleTags": [
              "tag2"
            ]
          }
        ]
      }
    ]
  }
]

[MichaelSimons]

Looks good, I have just a couple minor comments.

This is a type of change I think we should consider rolling out to nightly to validate before pushing it to the other repos. Perhaps it would make sense to create a feature branch to put these ImageInfo changes into and test with nightly then push out to the other repos. Creating a feature branch would allow us to make servicing fixes in master concurrently that can get pushed out to all of the repos.

[MichaelSimons]

LGTM - Any thoughts on my previous suggestion to use a feature branch?

[mthalman]

LGTM - Any thoughts on my previous suggestion to use a feature branch?

Oh right, thanks for the reminder. I'll do that.