Add first class fields to PackageRevision resource for upstream package name, revision, and repository name

[liamfallon]

Original issue URL: https://github.com/kptdev/kpt/issues/3453 Original issue user: https://github.com/ChristopherFry Original issue created at: 2022-08-10T21:18:22Z Original issue last updated at: 2022-11-15T22:53:58Z Original issue body: Requesting first class fields are created in the PackageRevision resource for the upstream package name, upstream revision, and upstream repository name.

Using first class fields eliminates the need of clients needing to parse status.upstreamLock in order to find the upstream package name and revision. Parsing the status.upstreamLock field alone isn't enough to find the repository name, so clients today also need to use the repository url and query Repositories to find the repository name (if registered). The three fields are needed to search upstream and downstream packages.

PackageRevision resource today:

apiVersion: porch.kpt.dev/v1alpha1
kind: PackageRevision
metadata:
  name: application-blueprints-7c3f2f699ad3495c48d81287c6f05a3f59ff2ed1
  namespace: default
  resourceVersion: 86bf85e0dcfc0125d39c521411c9f5545b4be2f8
spec:
  lifecycle: Published
  packageName: external-secrets-blueprint
  repository: application-blueprints
  revision: main
status:
  upstreamLock:
    git:
      commit: d5285bc400ecc10eff910a80866246bef0ff198f
      directory: external-secrets
      ref: external-secrets/v0
      repo: https://github.com/GoogleContainerTools/kpt-samples.git
    type: git

Original issue comments: Comment user: https://github.com/mortent Comment created at: 2022-08-10T22:31:54Z Comment last updated at: 2022-08-10T22:31:54Z Comment body: So it sounds like the problem here is that there isn't an easy way to go from the status.UpstreamLock to the actual porch package. The reason for this, is that the Kptfile where the upstreamLock is coming from isn't aware of porch, it just provide a reference directly to a package, using the storage format (git, oci, ..) for the package.

I don't think storing information about porch package in the Kptfile is a good direction. It seems to take us in a direction where managing package have to happen through porch. Also, we do allow creation of package through cloning directly from a git repo or a oci repo, in which case the upstreamLock can't be represented as a porch package.

It seems like the direction for supporting this would be for porch to translate from upstreamLock information to porch package references on the fly as a package is read. This would require that porch has enough information to do this mapping and I'm not sure if that will always be true.

Comment user: https://github.com/natasha41575 Comment created at: 2022-08-10T22:39:21Z Comment last updated at: 2022-08-10T22:39:21Z Comment body: > It seems like the direction for supporting this would be for porch to translate from upstreamLock information to porch package references on the fly as a package is read. This would require that porch has enough information to do this mapping and I'm not sure if that will always be true.

IIRC, this translation is currently happening on the client-side (e.g. on every kpt alpha rpkg update --discover). Unless I am missing something the implementation of this issue seems like it would largely be moving parts of that code from the CLI over to porch. Are there any reasons that the client is better informed or can do the mapping more reliably than porch can?