Add command to show historical runs of porter

[carolynvs]

On main, porter show includes historical run data, with the actions performed on the installation along with their claim id.

On release/v1, once we merge the installation spec support PR (#1684), that data is no longer included in show by default because it's not "free" data anymore and would require another query.

I propose that we split the show command into two commands, porter installation show (show the details of the installation) and porter installation runs list (list the historical runs for an installation). That gives the user more control over the data that will be provided and we don't make unnecessary (expensive) remote storage calls.

$ porter installation runs list [NAME] [--namespace NAMESPACE] [--output FORMAT]
RUN ID     ACTION     STARTED          STOPPED          STATUS
claimid    install    10 minutes ago   5 minutes ago    suceeded
claimid    upgrade    1 minute ago                      running

This requires that the command make a query to both the runs collection and the results collection, filtering by installation + namespace, and then combining the documents on the client.

[phillipahereza]

Hi @carolynvs can I work on this?

[carolynvs]

Sure! Let me know if you have any questions about how to get the necessary data to display. Feel free to make a draft pull request and ask questions there if you get partway implemented and run into trouble. 👍

[phillipahereza]

@carolynvs is the target branch for this PR main or release/v1? never mind, figured it out

[phillipahereza]

@carolynvs can a run really have multiple results? From this interface it kinda looks like it's possible. If this is possible, under what circumstances would it happen?

And if a run has multiple results, do I list all of them?

[carolynvs]

Most runs will have multiple "results" because every time porter updates the status of a run, it is a new result. The CNAB specification uses "append only" records, so we never update an existing record.

Here is a representative sample of what the data will look like:

• installation entry with its name
• a claim document for each time we execute the bundle. This represents a "run".
• each claim document will have two results
  • one marking when the run started, with a status of "running"

    {
    "id": "01EEX72V6W2CWH00G3DZ5KX2XY",
    "claimId": "01EEX72V6VPNDH7V2EC43R9N1C",
    "created": "2020-08-04T12:07:42.428088-05:00",
    "status": "running"
    }
    

  • another marking when the run completed, with a status of either "succeeded" or "failed" (there are other possible states, but this is just an example)

      {
        "id": "01EEX72VTVA9CDH1E5KSQRJAZJ",
        "claimId": "01EEX72V6VPNDH7V2EC43R9N1C",
        "created": "2020-08-04T12:07:43.067805-05:00",
        "status": "succeeded",
        "outputs": {
          "output1": {
            "contentDigest": "sha256:d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26"
          }
        }
      }
    

  • the last result will have associated output records

[carolynvs]

Fixed in #1779