WIP: Surface BuildRun Results List under Status

[qu1queee]

Changes

Adding BuildResults to the BuildRun Status object. This should allow us to surface valuable data to users, under the BuildResults list.

Today we are already producing Tekton results, such as:

• svn commit SHA
• image digest

which are available at a TaskRun level, under .status.taskResults , but not at the BuildRun level.

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from qu1queee after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[imjasonh]

I like the direction this is going, but I think we might want to surface the Git commit SHA and built image digest as specific typed fields in the status, since we expect these to be pretty common and highly used.

Other strategies might produce other results, and we should surface those as best we can, but source and output image information seems different to me.

We have the option of exposing this information in results and in typed fields, if we want to. Or we can extract it from the TaskRun's .status.results and filter it out of the BuildRun's .status.results if we want.

[imjasonh]

How about Results []Result, to match the yaml field name?

[imjasonh]

This would fix #618 and #205

[SaschaSchwarze0]

I also thought about how we could represent the data in the BuildRun status. Just to summarize, I see us eventually having three kinds of results:

1. Source-related results. These results may be there or not and be different, highly depending on how the user's build looks like. The naming pattern of the Tekton result is generally having the name of the source in there. Today, as HTTP sources produce no results and the Git type is only supported as "nameless" spec.source and gets the default name, it is way simpler.
2. Output-image-related results. These results are independent of the user's build and are the digest and size.
3. Build-strategy-defined results. Similar to params, there will eventually be results that a build strategy author defines and fills in the steps. My popular example: the Buildpacks strategies could report which main buildpack had been used.

To store this in the BuildRun status, there are two options:

1. The plain key-value list as proposed here. This would require that we document what the shp--prefixed result names are and what is in their value. Their names speak mostly for themselves, but I assume when one sees them for the first time, one needs a moment to understand them. Including the result's description (which is in the TaskSpec) would imo make sense.
2. A more complex data structure based on above three groups. This is more self-explaining. Numeric properties can become numbers (like the image size). For example like this:

status:
  sources:
    - name: default  # the Git source from spec.source
      git:
        commit-sha: abcd
        commit-author: qu1queee # assumes that we eventually expand what a Git source provides
    - name: license-file # an HTTP source from spec.sources
      http:
        size: 3278 # assumes that an HTTP source has a size result
  output-image:
    digest: sha:30213102
    size: 302173
  results:
    - name: the-custom-buildstrategy-defined-result
      value: some-value

I actually do not suggest to necessarily change what you have. Approach (1) is also fine with me.

[qu1queee]

late response here ( my bad ). I decided to move this into a SHIP, to allow more people to provide feedback on a proposal. This might delay even more the implementation, but I prefer to go this path.

[qu1queee]

Related SHIP shipwright-io/community#13 , closing as I cannot work on this one at the moment.

[qu1queee]

Feel free to take this item anyone.