Add the "repository", including "last change" to *build* events about spec

[e-backmark-ericsson]

I agree that we need to be able to correlate the build events with their corresponding change events, when such exists. I do however believe that we should not add mandatory properties to the build events with information that is duplicate of what is already provided in the change event(s). Instead we should make it possible to correlate the events with each other by other means, such as by "links" or by context type fields.
We should also be aware that it is not always a one-to-one mapping between an artifact and a source code repo. An artifact could take input from multiple source repos, and one source repo could produce multiple artifacts, so the solution we provide needs to cater for that. One way to deal with multiple sources used for one artifact would be through "compositions".

[afrittoli]

I agree that we need to be able to correlate the build events with their corresponding change events, when such exists. I do however believe that we should not add mandatory properties to the build events with information that is duplicate of what is already provided in the change event(s). Instead we should make it possible to correlate the events with each other by other means, such as by "links" or by context type fields.

I understand your point, but I still think that a build should contain information about the repository (or repositories) that are input to the build with their respective last change ID, because of a few reasons:

• a build is not necessarily associated to a change. There could be manually or periodically triggered builds for instance
• the repository information is relevant for routing and filtering use cases. A consumer may want to subscribe to all builds associated to a repository, and it won't be able to do so if the repository information is stored in a different event that has to be fetched from somewhere else
• SLSA level 4 requires parameterless builds, where the only inputs are the "build entry point" (I interpret that as repo, reference) and top-level source location, so it's fair to assume that that information will always be in a build
• I would like to keep the use case where the receiver may rely on a public store of events as optional

We should also be aware that it is not always a one-to-one mapping between an artifact and a source code repo. An artifact could take input from multiple source repos, and one source repo could produce multiple artifacts, so the solution we provide needs to cater for that. One way to deal with multiple sources used for one artifact would be through "compositions".

About the multiple repo to single artifact, I would take the approach of assuming single repo in the beginning and extending to multiple repos support when we hit that use case.
About the single repo to multiple artifact, we may want to include the "top-level source location" information, as also included in the SLSA level 4 parameterless description

[m-linner-ericsson]

When it comes to the SLSA level 4 I interpret that it requires that the person/engine triggering the build can't add in parameters but all parameters must be part of a build script or an input. E.g. if we would have a composition event this could serve as an input.

When it comes to what information should be added in the events we probably should state that in the spec. We have earlier had a discussion about "heavy" and "lightweight" events and I guess we are circling back to that discussion here. I would vote for not including repository information in this event just as @e-backmark-ericsson pointed out.

Also, if we decide to go for a repository it would be good if we could put some wording on binary vs source code builds. Some builds will not just use source code (text) but may well include binaries as input to the build.

Regarding

• a build is not necessarily associated to a change. There could be manually or periodically triggered builds for instance

If a build not associated to change why do you want to include the last change id?

[afrittoli]

When it comes to the SLSA level 4 I interpret that it requires that the person/engine triggering the build can't add in parameters but all parameters must be part of a build script or an input. E.g. if we would have a composition event this could serve as an input.

When it comes to what information should be added in the events we probably should state that in the spec. We have earlier had a discussion about "heavy" and "lightweight" events and I guess we are circling back to that discussion here.

I don't think this should bring back the discussion about "heavy" vs. "lightweight" but the fact that you bring this up is a signal that we should document out decisions about this in the spec or primer.

For me "lightweight" means that we include links to large content, rather than base64 encode it into a blob in the event.

I would vote for not including repository information in this event just as @e-backmark-ericsson pointed out.

I'm not quite sure I understand this, I think it would be useful to discuss in the cdevents meeting.
I'll add it to the agenda.

Also, if we decide to go for a repository it would be good if we could put some wording on binary vs source code builds. Some builds will not just use source code (text) but may well include binaries as input to the build.

I'm not sure I understand this either? A source repo does not imply that there are no binary dependencies.
Usually dependencies (binary and not) are expressed in the form of one or more file that is in the source repo.

There may be multiple repositories involved, but I would suggest to start with the case of one and extend it from there when we get to that situation in a poc.

Regarding

• a build is not necessarily associated to a change. There could be manually or periodically triggered builds for instance

If a build not associated to change why do you want to include the last change id?

The last change ID tells us the state of the repository against which the build was executed. The fact that the change happened at some point in time doesn't have to be the trigger of the current build.

[afrittoli]

Removed from the v0.1 scope. For the dora metrics we can rely on the artifact events alone.