cli icon indicating copy to clipboard operation
cli copied to clipboard

Enhance BuildRun List Reported Information

Open otaviof opened this issue 2 years ago • 6 comments

The sub-command buildrun list should show more information about the resource, as in the output-image, elapsed build time, creation date, and more. The current output is as follows:

$ shp buildrun list
NAME                    STATUS                          AGE
nodejs-ex-srqsc         BuildRegistrationFailed         0s

And we would like to add the following new columns:

  • ELAPSED-TIME: how long the build took, in case the build still running it should show how long has elapsed
  • OUTPUT-IMAGE: fully qualified image produced

What other columns should we add?

/cc @SaschaSchwarze0

otaviof avatar May 10 '22 13:05 otaviof

I think there should be the Build name.

I personally would like to see what my BuildRun did. I am just not sure how much we can put in the list. The source initially would be a Git repo plus potentially a revision, once it completed, we might even have a commit ID (or be something else for local or bundle). Same for the output, initially we only know the image URL, once it is completed, we can add the digest. I tend to think that this would be too long so that this might need to go into a shp buildrun get.

SaschaSchwarze0 avatar May 10 '22 13:05 SaschaSchwarze0

@otaviof @SaschaSchwarze0 this would be a good first issue/Hacktoberfest candidate if we could narrow the scope of this issue.

adambkaplan avatar Sep 28 '22 18:09 adambkaplan

I think there should be the Build name.

Indeed, that's useful information.

I personally would like to see what my BuildRun did. I am just not sure how much we can put in the list.

In kubectl the flag --wide shows more columns, we should adopt the same. And therefore we can have a wider set of columns reporting more the BuildRun details.

Lets try to enumerate all the columns we would like to see on shp buildrun list and decide later which should go to the --wide flag?

The source initially would be a Git repo plus potentially a revision, once it completed, we might even have a commit ID (or be something else for local or bundle). Same for the output, initially we only know the image URL, once it is completed, we can add the digest. I tend to think that this would be too long so that this might need to go into a shp buildrun get.

As a initial suggestion, those are the columns you described:

  • SOURCE: shows the Build's .spec.source.url and .spec.source.revision, upon BuildRun completion it adds the short commit diggest. For example: github.com/shipwright-io/build@main and upon completion github.com/shipwright-io/build@shortdigest
  • OUTPUT-IMAGE: what I suggested earlier;
  • IMAGE-DIGEST: SHA256 digest of the output image pushed to the registry;
  • SOURCE-ORIGIN: describes the origin of the source code employed on the BuildRun, can be one of the following:
    • repository: came from the repository on .spec.source.url;
    • bundle: came from a bundle container image;
    • upload: came from local source upload;

otaviof avatar Oct 10 '22 07:10 otaviof

Yep, sounds good @otaviof re --wide. One thing I would like is that we expose the creationTimestamp somehow as an Age. I tbh do not know what Kubernetes does there with pods, nodes, etc, But tools like k9s have special handling when there is an Age column and then allow sorting on it which I use every day and always am disappointed when I can't do it for BuildRuns. :-)

SaschaSchwarze0 avatar Oct 19 '22 12:10 SaschaSchwarze0

@SaschaSchwarze0 I also like the idea of showing the "age" of the BuildRun, that's useful information 👍

Do you think we should tackle all columns needed at the same time, or maybe, having one issue per column? Perhaps, small work items are better for the Hacktoberfest. What do you think, @adambkaplan?

otaviof avatar Oct 19 '22 14:10 otaviof

I tend to "all at once". At least sounds like a lot paperwork and the intermiete state might look weird?

SaschaSchwarze0 avatar Oct 19 '22 15:10 SaschaSchwarze0