Actions - Traceability Schema

[rachitb777]

                                                  Traceability Schema

Abstract Traceability involves ability to track the source for issue, code, commit, artifact, workflow, and the user from the package deployed on the resource, through documented records. This document proposes the traceability schema which captures the traceability data for any deployment which can be used by any "CI/CD" providers and cloud providers to organize the traceability data and consume it in various forms.

Format: The schema organizes the information in the following way

• Categorization of various sections :

  • How did it get deployed ? Captures the commit and workflow details was the trigger and resulted in the deployment of a generated artifact to a resource

  • What was deployed ? Captures the artifacts’ details that has been deployed

  • Where did it get deployed ? Captures the target resource where the deployment has happened.

    The “How” and “Where” part can come from various providers which the schema factors in by having a provision to have any new source “type/provider” to use the schema to generate the traceability data or a cloud provider to deploy the data onto its respective cloud. This definition of the schema makes it agnostic to both cloud providers (Azure, AWS, GCP ,Kusto) as well as source control providers (GitHub, ADO, Bitbucket).

• Representation of a specific section: Data is organized into the following in each of the section/categorizes within the traceability data -

  • "Category of data"
    • "Provider of the data"
      • Associated properties specific to the provider
        • The data is organized into multiple subsections/objects as appropriate.
        • The data is organized into objects factoring in the hierarchy. Will restrict to a depth of two. Building the tree is outside the scope and goal of this schema.
        • The data in the property bag does not follow the paradigm of include all rather follows the paradigm of include relevant/important data which will help consumer to trace deployment of an artifact on a resource and the trace the change in resource that resulted due to the act of deployment
        • We will continuously review the deployment traceability needs on various resources and artifacts across cloud types, involve the community for feedback and review the property bag schema accordingly.

{
   "id": " " /* The unique identifier of the traceability object. The intent is for this to be unique, 
                     filtering on this is not an ask as yet */

   "timestamp" : " " /* The timestamp of the creation of traceability object */  

   "schema-version": " " /* Schema version of the traceability object */

   "data":{  /* This section captures all the traceability data split into three subsections of devops, artifacts 
                     and target resource */

       "devops": {  /* This section captures the information related to the code hosting or CI/CD platform. */

           "type": " " /* This is the provider/type of the CI/CD or code hosting platform. GitHub, ADO, BB Pipelines etc. 
                              can be the possible types along with many others. */

           "properties" :{ 
                /*  The contents of this property bag would depend on the constructs and entities pertaining
                    to the type of CI/CD provider specified in the above field.  This will broadly encompass 
                    information on commits, pipelines, workflow runs, Issues etc. 
               */ 
           }
       },

       "artifact": { /* This section captures the information of the associated artifacts */

           "type" : " " /* This is the type of artifact. It can be a build artifact or an Image artifact. 
                                 For ex. Docker file, Manifest, container Image, JAR etc.*/

           "properties":{
                        /* This property bag captures detailed information of the source and other properties 
                            of the associated artifact.
                            A broad classification of the usage of artifact type will be as follows - 
                                       For target resource as the Image registery the artifact section would contain the 
                                       build artifacts that were used to produce the Image.
                                       For target resource as the AKS/WebApp/DB the artifact section would contain the 
                                       Information on the source of the Image and other data associate to Image that is
                                       deployed on the resource. 
                           For example, 
                           Docker file - This property bag would contain associated information like repository, path, 
                                         commit associated with the same 
                           Image       - This property bag would contain associated information like repository, registry, 
                                          Image SHA etc. associated with the Image.
                      */
           },
       },
       "target resource":{ 
                         /* This is target resource to which the deployment has happened. It would typically be the 
                            cloud provider like ACR, Azure, AWS and GCP.  The definition is the prerogative of the cloud
                            provider who is consuming this traceability object */

           "type": " ", /* This will be the cloud provider type like Azure,AWS, GCP etc. Can also extend to any other
                                 traceability stores like Kusto, AI and others */

             "StartTimestamp":"" /* Start time stamp of the deployment */

             "EndTimestamp":""  /* End time stamp of the deployment */

               "properties":{
                               /*  */
                   },
               },
       "strategy" : {
           "type":  "./* This is the type of deployment strategy getting used for current deployment. Example can be canary, blue-green etc". 
           "properties": {
                     /* Specific details of the deployment strategy. This is a set of key value pair"
               }
           }
       }  
   } 

Examples: AWS

   "id": "cdfed638-6530-40cb-8d26-ce503cddb207", 
   "timestamp" : "2020-06-04T07:59:40Z",
   "schema-version": "alpha-1", 
   "data":{
       "devops": {
           "type": "GitHubActions", 
           "properties":{
               "run":{ 
                   "workflow":{
                       "repository": "contoso/contoso-app",
                       "path": "./github/workflow/cd.yml",
                       "name": "Contoso Deployment",
                       "ref": "refs/heads/release",
                       "commit": "commitSHA"
                   },
                   "trigger":{
                       "type": "on push"
                       "properties": {  
                           "user": "user", 
                           "timestamp": "timestamp", 
                           "commit": "commitSHA"
                       },
                   },
                   "id": 123,
               }
           }
       },
       "artifact": {
           "type" : "containerImage", 
           "properties":{
               "image":{ 
                   "imageSHA":"SHA1",
                   "registryProvider":"ECR",
                   "image-repository": "account-service",
                   "container-registry": "myRegistry" 
               },
           },
       },
    "resource": { 
        "type": "AWS",
        "properties": {
            "resourcetype": "AWS::EC2::Instance",
            "Resources": {
                "Ec2Instance": {
                    "Type": "AWS::EC2::Instance",
                    "Properties": {
                        "SecurityGroups": [
                            {
                                "Ref": "InstanceSecurityGroup"
                            },
                            "MyExistingSecurityGroup"
                        ],
                        "AvailabilityZone": "us-east-1a",
                        "KeyName": "mykey",
                        "ImageId": "ami-7a11e213"
                    }
                },
                "InstanceSecurityGroup": {
                    "Type": "AWS::EC2::SecurityGroup",
                    "Properties": {
                        "GroupDescription": "Enable SSH access via port 22",
                        "SecurityGroupIngress": [
                            {
                                "IpProtocol": "tcp",
                                "FromPort": "22",
                                "ToPort": "22",
                                "CidrIp": "0.0.0.0/0"
                            }
                        ]
                    }
                }
            }
        },
        "updatestartTimestamp": "",
        "updateendTimestamp": ""
    }  

   } 
}

Example2:  DockerFile to ACR
{
   "id": "cdfed638-6530-40cb-8d26-ce503cddb207", // ID for tracebility mapping object 
   "timestamp" : "2020-06-04T07:59:40Z", // timestamp when traceability mapping object was created 
   "schema-version": "alpha-1", // Schema version for traceability mapping object to accomodate breaking changes
   "data":{
       "devops": {
           "type": "GitHubActions", // Others being ADO, BB pipelines, we have prioritized GH Actions. for other CI/CD provider property bag will be updated accordingly
           "properties":{
               "run":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns.  
                   "workflow":{
                       "repository": "contoso/contoso-app",
                       "path": "./github/workflow/cd.yml",
                       "name": "Contoso Deployment",
                       "ref": "refs/heads/release",
                       "commit": "commitSHA"
                   },
                   "trigger":{
                       "type": "on push",// ( others can be issueResolved, onCommit ... and property bag will be updated accordingly )
                       "properties": { // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                           "user": "user", // triggered By
                           "timestamp": "timestamp", // triggered at 
                           "commit": "commitSHA" // trigerring commit
                       },
                   },
                   "id": 123,
               }
           }
       },
       "artifact": {
           "type" : "dockerfile", // ( others can be  containerImage, JAR, k8sartifact .... and property bag will be updated accordingly )
           "properties":{
               "file":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                   "repository": "contoso1/contoso-app",
                   "path": "/application",
                   "name": "DockerFile",
                   "ref": "refs/heads/release",
                   "commit": "commitSHA"
               },
           },
       },
       "resource":{// will be contributed by cloud providers
           "type": "Azure", //( others can be AWS, GCP, Digital Ocean .. and property bag will be updated accordingly)
               "properties":{
                   "id": "/subscriptions/c00d16c7-6c1f-4c03-9be1-6934a4c49682/resourceGroups/k8sRg/providers/Microsoft.ACR/4a4c49adaada",
                   "resourcetype": "Microsoft.ACR",
                   "properties":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                       "imageSHA":"SHA1",
                       "historicalImageSHAs": "",
                       "registryProvider":"ACR",
                       "image-repository": "account-service",
                       "container-registry": "myRegistry" 
                   },
                   "updatestartTimestamp":"",
                   "updateendTimestamp":""
               }
       }  
   } 
}

Example3:  ACR to AKS
{
   "id": "cdfed638-6530-40cb-8d26-ce503cddb207", // ID for tracebility mapping object 
   "timestamp" : "2020-06-04T07:59:40Z", // timestamp when traceability mapping object was created 
   "schema-version": "alpha-1", // Schema version for traceability mapping object to accomodate breaking changes
   "data":{
       "devops": {
           "type": "GitHubActions", // Others being ADO, BB pipelines, we have prioritized GH Actions. for other CI/CD provider property bag will be updated accordingly
           "properties":{
               "run":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns.  
                   "workflow":{
                       "repository": "contoso/contoso-app",
                       "path": "./github/workflow/cd.yml",
                       "name": "Contoso Deployment",
                       "ref": "refs/heads/release",
                       "commit": "commitSHA"
                   },
                   "trigger":{
                       "type": "on push",// ( others can be issueResolved, onCommit ... and property bag will be updated accordingly )
                       "properties": { // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                           "user": "user", // triggered By
                           "timestamp": "timestamp", // triggered at 
                           "commit": "commitSHA" // trigerring commit
                       },
                   },
                   "id": 123,
               }
           }
       },
       "artifact": {
           "type" : "containerImage", // ( others can be  JAR, k8sartifact .... and property bag will be updated accordingly )
           "properties":{
               "image":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                   "imageSHA":"SHA1",
                   "registryProvider":"ACR",
                   "image-repository": "account-service",
                   "container-registry": "myRegistry" 
               },
           },
       },
       "resource":{// will be contributed by cloud providers
           "type": "Azure", //( others can be AWS, GCP, Digital Ocean .. and property bag will be updated accordingly)
               "properties":{
                   "ID": "/subscriptions/c00d16c7-6c1f-4c03-9be1-6934a4c49682/resourceGroups/k8sRg/providers/Microsoft.ContainerService/managedClusters/contoso-k8s-cluster",
                   "resourcetype": "Microsoft.ContainerService/ManagedClusters",
                   "properties":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                       "namespace": "prod-wcus",
                       "kubernetesObjects": [
                           {
                               "kind": "services",
                               "name": "contoso-service",
                               "version": "v1"
                           },
                           {
                               "kind": "deployments",
                               "name": "contoso-deployment",
                               "version": "v1"
                           }
                       ]
                   },
                   "updatestartTimestamp":"",
                   "updateendTimestamp":""
               }
       },
       "strategy": {
           "type" : "canary" 
           "properties": {
                "percentage": 25
           }
      }
   } 
}

Example4:  Node to Webapp 
{
   "id": "cdfed638-6530-40cb-8d26-ce503cddb207", // ID for tracebility mapping object 
   "timestamp" : "2020-06-04T07:59:40Z", // timestamp when traceability mapping object was created 
   "schema-version": "alpha-1", // Schema version for traceability mapping object to accomodate breaking changes
   "data":{
       "devops": {
           "type": "GitHubActions", // Others being ADO, BB pipelines, we have prioritized GH Actions. for other CI/CD provider property bag will be updated accordingly
           "properties":{
               "run":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns.  
                   "workflow":{
                       "repository": "contoso/contoso-app",
                       "path": "./github/workflow/cd.yml",
                       "name": "Contoso Deployment",
                       "ref": "refs/heads/release",
                       "commit": "commitSHA"
                   },
                   "trigger":{
                       "type": "on push",// ( others can be issueResolved, onCommit ... and property bag will be updated accordingly )
                       "properties": { // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                           "user": "user", // triggered By
                           "timestamp": "timestamp", // triggered at 
                           "commit": "commitSHA" // trigerring commit
                       },
                   },
                   "id": 123,
               }
           }
       },
       "artifact": {
           "type" : "nodefile", // ( others can be  containerImage, JAR, k8sartifact .... and property bag will be updated accordingly )
           "properties":{
               "file":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                   "repository": "contoso1/contoso-app",
                   "path": "/application",
                   "name": "package.json",
                   "ref": "refs/heads/release",
                   "commit": "commitSHA"
               },
           },
       },
       "resource":{// will be contributed by cloud providers
           "type": "Azure", //( others can be AWS, GCP, Digital Ocean .. and property bag will be updated accordingly)
               "properties":{
                   "id": "/subscriptions/afc11291-9826-46be-b852-70349146ddf8/resourcegroups/contosoRG/providers/Microsoft.Web/sites/contosoApp/appServices",
                   "resourcetype": "Microsoft.AppService",
                   "properties":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                       "slot-name":"staging",
                   },
                   "updatestartTimestamp":"",
                   "updateendTimestamp":""
               }
       }  
   } 
}

Example5:  NPM to Webapp 
{
   "id": "cdfed638-6530-40cb-8d26-ce503cddb207", // ID for tracebility mapping object 
   "timestamp" : "2020-06-04T07:59:40Z", // timestamp when traceability mapping object was created 
   "schema-version": "alpha-1", // Schema version for traceability mapping object to accomodate breaking changes
   "data":{
       "devops": {
           "type": "GitHubActions", // Others being ADO, BB pipelines, we have prioritized GH Actions. for other CI/CD provider property bag will be updated accordingly
           "properties":{
               "run":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns.  
                   "workflow":{
                       "repository": "contoso/contoso-app",
                       "path": "./github/workflow/cd.yml",
                       "name": "Contoso Deployment",
                       "ref": "refs/heads/release",
                       "commit": "commitSHA"
                   },
                   "trigger":{
                       "type": "on push",// ( others can be issueResolved, onCommit ... and property bag will be updated accordingly )
                       "properties": { // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                           "user": "user", // triggered By
                           "timestamp": "timestamp", // triggered at 
                           "commit": "commitSHA" // trigerring commit
                       },
                   },
                   "id": 123,
               }
           }
       },
       "artifact": {
           "type" : "npmpackage", // ( others can be  containerImage, JAR, k8sartifact .... and property bag will be updated accordingly )
           "properties":{
               "package":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 

               },
           },
       },
       "resource":{// will be contributed by cloud providers
           "type": "Azure", //( others can be AWS, GCP, Digital Ocean .. and property bag will be updated accordingly)
               "properties":{
                   "id": "/subscriptions/afc11291-9826-46be-b852-70349146ddf8/resourcegroups/contosoRG/providers/Microsoft.Web/sites/contosoApp/appServices",
                   "resourcetype": "Microsoft.AppService",
                   "properties":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                       "slot-name":"staging",
                   },
                   "updatestartTimestamp":"",
                   "updateendTimestamp":""
               }
       }  
   } 
}

Example6:  2 images to AKS : we will create/send 2 traceability objects. One for each image. 
{
   "id": "cdfed638-6530-40cb-8d26-ce503cddb207", // ID for tracebility mapping object 
   "timestamp" : "2020-06-04T07:59:40Z", // timestamp when traceability mapping object was created 
   "schema-version": "alpha-1", // Schema version for traceability mapping object to accomodate breaking changes
   "data":{
       "devops": {
           "type": "GitHubActions", // Others being ADO, BB pipelines, we have prioritized GH Actions. for other CI/CD provider property bag will be updated accordingly
           "properties":{
               "run":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns.  
                   "workflow":{
                       "repository": "contoso/contoso-app",
                       "path": "./github/workflow/cd.yml",
                       "name": "Contoso Deployment",
                       "ref": "refs/heads/release",
                       "commit": "commitSHA"
                   },
                   "trigger":{
                       "type": "on push",// ( others can be issueResolved, onCommit ... and property bag will be updated accordingly )
                       "properties": { // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                           "user": "user", // triggered By
                           "timestamp": "timestamp", // triggered at 
                           "commit": "commitSHA" // trigerring commit
                       },
                   },
                   "id": 123,
               }
           }
       },
       "artifact": {
           "type" : "containerImage", // ( others can be  JAR, k8sartifact .... and property bag will be updated accordingly )
           "properties":{
               "image":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                   "imageSHA":"SHA1",
                   "registryProvider":"ACR",
                   "image-repository": "account-service",
                   "container-registry": "myRegistry" 
               },
           },
       },
       "resource":{// will be contributed by cloud providers
           "type": "Azure", //( others can be AWS, GCP, Digital Ocean .. and property bag will be updated accordingly)
               "properties":{
                   "ID": "/subscriptions/c00d16c7-6c1f-4c03-9be1-6934a4c49682/resourceGroups/k8sRg/providers/Microsoft.ContainerService/managedClusters/contoso-k8s-cluster",
                   "resourcetype": "Microsoft.ContainerService/ManagedClusters",
                   "properties":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                       "namespace": "prod-wcus",
                       "kubernetesObjects": [
                           {
                               "kind": "services",
                               "name": "contoso-service",
                               "version": "v1"
                           },
                           {
                               "kind": "deployments",
                               "name": "contoso-deployment",
                               "version": "v1"
                           }
                       ]
                   },
                   "updatestartTimestamp":"",
                   "updateendTimestamp":""
               }
       }  
   } 
}
{
   "id": "cdfed638-6530-40cb-8d26-ce503cddb207", // ID for tracebility mapping object 
   "timestamp" : "2020-06-04T07:59:40Z", // timestamp when traceability mapping object was created 
   "schema-version": "alpha-1", // Schema version for traceability mapping object to accomodate breaking changes
   "data":{
       "devops": {
           "type": "GitHubActions", // Others being ADO, BB pipelines, we have prioritized GH Actions. for other CI/CD provider property bag will be updated accordingly
           "properties":{
               "run":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns.  
                   "workflow":{
                       "repository": "contoso/contoso-app",
                       "path": "./github/workflow/cd.yml",
                       "name": "Contoso Deployment",
                       "ref": "refs/heads/release",
                       "commit": "commitSHA"
                   },
                   "trigger":{
                       "type": "on push",// ( others can be issueResolved, onCommit ... and property bag will be updated accordingly )
                       "properties": { // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                           "user": "user", // triggered By
                           "timestamp": "timestamp", // triggered at 
                           "commit": "commitSHA" // trigerring commit
                       },
                   },
                   "id": 123,
               }
           }
       },
       "artifact": {
           "type" : "containerImage", // ( others can be  JAR, k8sartifact .... and property bag will be updated accordingly )
           "properties":{
               "image":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                   "imageSHA":"SHA2",
                   "registryProvider":"ACR1",
                   "image-repository": "hello-service",
                   "container-registry": "yourRegistry" 
               },
           },
       },
       "resource":{// will be contributed by cloud providers
           "type": "Azure", //( others can be AWS, GCP, Digital Ocean .. and property bag will be updated accordingly)
               "properties":{
                   "ID": "/subscriptions/c00d16c7-6c1f-4c03-9be1-6934a4c49682/resourceGroups/k8sRg/providers/Microsoft.ContainerService/managedClusters/contoso-k8s-cluster",
                   "resourcetype": "Microsoft.ContainerService/ManagedClusters",
                   "properties":{ // These are key fields which we have identified based on our understandng of traceability needs. Will expand them as more scenarios uneartherns. 
                       "namespace": "prod-wcus",
                       "kubernetesObjects": [
                           {
                               "kind": "services",
                               "name": "contoso-service",
                               "version": "v1"
                           },
                           {
                               "kind": "deployments",
                               "name": "contoso-deployment",
                               "version": "v1"
                           }
                       ]
                   },
                   "updatestartTimestamp":"",
                   "updateendTimestamp":""
               }
       }  
   } 
}

/* Open Items that is being worked on
   Deployment Strategy - Factor it in the Schema , as part of the Resource as a reflection and as a deployment base object as configuration is one way.
   Workflow Status -  Workflow may have a cascade of actions and at any point the status may not have relevance. It is more a command executed as part of actions itself
*/

[kmkumaran]

Discussion Notes:

1. Schema needs a version, so that we can handle back compatibility as we rev this.
2. Is Provider a Mandatory or Optional? Would you have predefined providers (Azure, AWS, GCP, OnPrem) listed or will any 'string' be ok?
3. Would Target resource type be a URI or String? Is it String because we need the schema to scale to On-premise targets?
4. I am assuming we are supporting only GitHub provider for Workflow. This seem like a good scoping call.
5. I am assuming that schema validation will look for "String : String" in Property bag for TargetResource, but will have rich strongly type schema validation for GitHub property bag in Workflow properties.
6. Remove the bootstrapconfiguration property from Workflow properties
7. Can you rephrase the "Purpose" column to explain the real need of those properties, instead of just explanation on their names.
8. Do we need to take traceability down all the way till Actions. Example: Multiple Action with same job can target same resource with different deployment status. How do we uniquely trace that?
9. Should Artifacts also have Provider, type and Property bag instead of flat properties?
10. Can we add one example for IaaS (VM Deployment) and one example for PaaS (AWS Beanstalk) with different artifact sources (Build drop and NPM or Nuget Package)

[kmkumaran]

Here are few more open questions that came up in review with @smalpani-gh

1. DockerFileUrl demands that Docker image be downloaded so that we can inspect the tag. This will be extra step during CD. Should this download be done just for traceability?
2. Clarify where the k8s Deployment object traceability belongs, is it in targetResource properties or within the artifact properties?
3. Why do we need Manifest Url? Who is the consumer?
4. What is modified timestamp for a workflow run?
5. Does jobName belong to workflowRun or workfFlow? Clarify.
6. Why is workflow properties not a Uri but instead name/path etc?
7. Why does dockerFile, Helm and Manifest Url all under artifact and not in Workflow inputs?
8. How can user start from Azure and trace the information to which k8s deployment applied the configuration and which workflow deployment applied the configuration. Clarify the flow and which properties will be used in those cases.

cc: @rachitb777 , @ammohant , @azooinmyluggage , @pulkitaggarwl , @ds-ms

[ammohant]

1. Yes, traceability would need this step to surface the Docker file against the deployment resource. The Docker file path is stored as a label in the docker image.
2. K8s Deployment is the run time kubernetes object create in the cluster. It belongs to the Target resource.
3. The AKS deployment centre spec demanded surfacing the manifest in the UI. In general if there is an intent to see if the desired and the current state differ, manifest can help in deriving that information along with the cluster state.
4. Inherited the definition from the proposed workflow resource. Modified timestamp can be done away with
5. JobName belongs to workflow
6. Artifact we have URIs as the source of the same can vary and hence URI, workflow path is the workflow identifier
7. Open item for discussion , can consider moving it to action context within workflow section or target resource k8s context
8. Details of the entry point to our experience can be found here

[azooinmyluggage]

What is the right naming : Is it Microsoft/GitHub/........? Examples https://github.com/opencontainers/image-spec/blob/master/annotations.md. http://label-schema.org/rc1/

[azooinmyluggage]

Artifact: What other types will be there and why everything for K8s is of type container artifact.

[azooinmyluggage]

Design question : How can we work around the need to download image and running docker inspect

[ammohant]

Design question : How can we work around the need to download image and running docker inspect

Two ways that we have discussed earlier. One is store it somewhere just like ADO but we understood from GH is building some sort of a store that we can leverage. Second is to have an environment variable store the Docker file path , this is not a full proof way.

[ammohant]

@smalpani-gh - This the final schema for the traceability we are closing on. Pls let us know of comments if any.

@rachitb777 @rohit-batra We can commit the final version of the schema once Sanjay gives the go ahead.

[koushdey]

@rachitb777 Can I close this issue since we have deferred this work? We can open a new issue when we plan to pick this up.