Support buildMetadata: [originAnnotations] in kustomize cfg tree

[ringerc]

Is your feature request related to a problem? Please describe.

kustomize cfg tree can be used to report the annotations from the buildMetadata: [originAnnotations] feature (see #3979 ) but it's difficult to work out how to select the field, and the output is confusing to read.

Short example, munged to show only layout, follows. Easy to repro with anything that has a remote base and a buildMetadata: [originAnnotations] entry in the kustomization.yaml:

$ kustomize build xxxx |  kustomize cfg tree --graph-structure directory --name --field 'metadata.annotations.config\.kubernetes\.io/origin' -
...
├── [.]  Deployment xxxx/xxxx
│   ├── metadata.annotations.config.kubernetes.io/origin: |
  path: xxxx/xxx/xxx/xxx.yaml
  repo: https://github.com/xxxx/xxxx
  ref: v1.0.0
│   └── spec.template.spec.containers
│       └── 0
│           └── name: manager
...

Describe the solution you'd like

• Add a --origin-annotations option to kustomize cfg tree that shows these origin annotations without needing to write a field selector with escapes etc
• Abbreviate the origin annotation in the output to simply origin or similar
• Indent multi-line output for annotations to improve readability of the output

something like

$ kustomize build xxxx |  kustomize cfg tree --graph-structure directory --name --origin-annotations -
...
├── [.]  Deployment xxxx/xxxx
│   ╞══ origin: |
│   │       path: xxxx/xxx/xxx/xxx.yaml
│   │       repo: https://github.com/xxxx/xxxx
│   │       ref: v1.0.0
│   └── spec.template.spec.containers
│       └── 0
│           └── name: manager
...

Note the presentation of entries that are not keys differently.

Describe alternatives you've considered

Since this relates to the interaction of two kustomize features, none really. I can live with what's there already, and it's fantastic, it'd just be really nice to prettify it.

I'm trying to get a CRA signed in the hope I might be able to PR something for this later but it's going to take a while...

Additional context

#3979

[natasha41575]

One thing to note is that we are hoping to graduate and potentially rename the kustomize cfg commands, see the issue here: #4090. It would probably be better if that issue could be completed before this one.

However, I'm not opposed to adding an option to the readonly commands to print out the origin, perhaps something like kustomize scan tree --origin. In fact I think this would go really well with the proposal in #4090 for the cfg commands to inflate the kustomizations by default before producing the output, removing the need to manually run and pipe the output ofkustomize build into the cfg commands.

[natasha41575]

/triage accepted
/kind feature

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.