option for origin data as annotation

[natasha41575]

Addresses #3979

This PR adds a top-level field to the kustomization:

buildMetadata: [originAnnotations]

This will add the following annotation to local files:

config.kubernetes.io/origin: |
  path: ../base/deployment.yaml

where path is the path to the file where the resource originated from, rooted at the directory upon which kustomize build is invoked.

For resources from remote bases, e.g. with the following kustomization.yaml:

resources:
- github.com/kubernetes-sigs/kustomize/examples/multibases/dev/?ref=v1.0.6
buildMetadata: [originAnnotations]

this will add the following annotation

config.kubernetes.io/origin: |
  path: examples/multibases/base/pod.yaml
  repo: https://github.com/kubernetes-sigs/kustomize
  ref: v1.0.6

where path is the path to the resource rooted at the root of the remote repository. ref will be omitted if the remote URL doesn't have one.

See tests at buildoptions_test.go and remoteload_test.go.

ALLOW_MODULE_SPAN

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: natasha41575

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [natasha41575]

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

[monopole]

Thanks for tackling this. It's complicated.

[monopole]

This is an important entry point, and its argument should be explained.

Does the method change it / take ownership of it (presumably yes, since a ptr is sent).
Is the outside owner expected to consult it?
What makes it change?

[natasha41575]

added a comment explanation

[monopole]

Likewise, this anno construction code should live in origin, with regression coverage (examples) in origin_test.go

[natasha41575]

Moved and tests are added in origin_test.go

[natasha41575]

@KnVerey @monopole PTAL

[natasha41575]

@yuwenma

[monopole]

/lgtm

thanks!

[ringerc]

This is brilliant, it's exactly what I've been looking for.

I don't see any way to specify the top-level origin without invoking kustomize directly on a remote base though. If I'm looking at a deployed resource with

metadata:
  annotations:
    config.kubernetes.io/origin: |
      path: serviceAccount.yaml

ideally I want to see something about where that serviceAccount.yaml came from.

I presume the best option here is to inject your own annotations with Kustomize commonAnnotations at the top level with an originating repo URI or the like. That should work well enough, though it'll be a bit fragile with layering. Ideally I'd want to be able to tell Kustomize the "origin" of the top level, so it records top-level origins fully qualified as well.

In any case, brilliant to see this, and thankyou.

[natasha41575]

@ringerc I'm not sure I understand the use case. If you use a remote base, you should see the repo and ref in the origin annotation as well.

e.g.

kustomization.yaml

resources:
- github.com/kubernetes-sigs/kustomize/examples/multibases/dev/?ref=v1.0.6
buildMetadata: [originAnnotations]

will have the following annotation:

config.kubernetes.io/origin: |
  path: examples/multibases/base/pod.yaml
  repo: https://github.com/kubernetes-sigs/kustomize
  ref: v1.0.6

Is this a different scenario from the one you are describing?

EDIT: I think I understand what you mean actually. Yeah, I think your use case is best done by using commonAnnotations. This feature only supports telling you where the resources originated relative to where kustomize build is run.