Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

patches is applied in different order than patchesJson6902 #5875

Open
ralgozino opened this issue Mar 17, 2025 · 1 comment
Open

patches is applied in different order than patchesJson6902 #5875

ralgozino opened this issue Mar 17, 2025 · 1 comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@ralgozino
Copy link

ralgozino commented Mar 17, 2025

What happened?

tl;dr: while patchesJson6902 is applied after commonLabels (and labels), patches is applied before commonLabels and labels.

I was updating a kustomize v3.10.0 project to v5.6.0. The build was running fine and gave the same output with kustomize v5.6.0 than with v3.10.0, but I got a warning that patchesJson6902 and commonLabels were deprecated and I should update to patches and labels respectively.

After switching to the "new" patches and labels the output changed. A lot of debugging later, I realised that patches is applied after labels (and commonLabels) while patchesJson6902 is applied before labels (and commonLabels).

FYI: I did the migration first with kustomize edit fix and then manually just in case the automatic migration did something odd, but got the same result in both cases.

What did you expect to happen?

I expected that switching from patchesJson6902 to patches would give me the same result, as documented, but instead the output changed.

If this change in behaviour is by design it should be mentioned in the documentation. Current docs make you believe that switching from patchesJson6902 to patches is straight-forward (it is true for most cases)

How can we reproduce it (as minimally and precisely as possible)?

# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- pod.yaml

labels:
  - pairs:
      my: value

patches:
  - target:
      kind: Pod
      version: v1
      name: myPod
    patch: |-
      - op: replace
        path: /metadata/labels
        value:
          patch: patches

#patchesJson6902:
#  - target:
#      kind: Pod
#      version: v1
#      name: myPod
#    patch: |-
#      - op: replace
#        path: /metadata/labels
#        value:
#          patch: patchesJson
#pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  containers:
    - name: dummy
      image: dummy

Expected output

apiVersion: v1
kind: Pod
metadata:
  labels:
    patch: patchesJson
  name: myPod
spec:
  containers:
  - image: dummy
    name: dummy

Actual output

apiVersion: v1
kind: Pod
metadata:
  labels:
    my: value
    patch: patches
  name: myPod
spec:
  containers:
  - image: dummy
    name: dummy

The expected output is what you get if you comment the patches section and uncomment the patchesJson6902 section in the kustomization.yaml file above.

Kustomize version

5.6.10

Operating system

MacOS

@ralgozino ralgozino added the kind/bug Categorizes issue or PR as related to a bug. label Mar 17, 2025
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Mar 17, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

ralgozino added a commit to sighupio/module-ingress that referenced this issue Mar 17, 2025

Verified

This commit was signed with the committer’s verified signature.
ralgozino Ramiro Algozino
Update kustomize projects to v5, dropping depreated fields like
`commonLabels`, `patchesJson6902`, and `patchesStrategicMerge`.

I found a bug (IMO) with kustomize v5: `patches` are applied before
`commonLabels` (and `labels`) where `patchesJson6902` were applied after
`commonLabels` (and `labels`).
Ref: kubernetes-sigs/kustomize#5875

This has the side effect that the configmap and certificate now have an
additional label `type: external` (or `type: internal`, respectively).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

No branches or pull requests

2 participants