Bug: Wildcard patches are not applied to all items when target key exists only in some objects

[d-enk]

Description

When using profile patches with a wildcard path (e.g. images.*.docker), the patch is applied only to items where the target key already exists, if at least one item explicitly defines this key in the base config.

This happens for both op: replace and op: add.

As a result, items that do not define the key are skipped, even though the wildcard path matches them logically.

---

DevSpace version

DevSpace version : 6.3.18

---

Reproducible example

version: v2beta1
name: test

profiles:
  - name: use_docker_cli
    patches:
      - op: replace
        path: images.*.docker
        value:
          useCli: true
      # same behavior with:
      # - op: add

images:
  image1:
    image: image1
    docker: {}

  image2:
    image: image2

---

Command

devspace print -p use_docker_cli --skip-info

---

Actual behavior

images:
  image1:
    image: image1
    docker:
      useCli: true
  image2:
    image: image2

🔴 docker.useCli is not added to image2.

---

Expected behavior

images:
  image1:
    image: image1
    docker:
      useCli: true
  image2:
    image: image2
    docker:
      useCli: true

The wildcard patch should be applied to all images, regardless of whether docker was defined in the base config.

---

Additional observation

If docker is removed from all images in the base config:

images:
  image1:
    image: image1
  image2:
    image: image2

Then the same patch works correctly and creates docker.useCli for both images.

---

Why this is problematic

• Wildcard patches behave inconsistently depending on base config shape
• op: add and op: replace do not create missing keys when mixed with existing ones
• Makes it difficult to apply global defaults via profiles

[lizardruss]

This is by design to prevent unexpectedly adding config where it doesn't exist. path is essentially yaml-jsonpath matcher, so the operation doesn't apply to items it doesn't match.

That said, you can use this to accomplish your goal, it only needs to be slightly more explicit. For example, this profile definition adds an operation to add docker: {} to where it doesn't exist, and then configures it with useCli: true.

devspace.yaml

version: v2beta1
name: test

profiles:
  - name: use_docker_cli
    patches:
      - op: add
        path: images.*[?(!@.docker)]
        value:
          docker: {}
      - op: add
        path: images.*.docker
        value:
          useCli: true

images:
  image1:
    image: image1
    docker: {}

  image2:
    image: image2

output

version: v2beta1
name: test
images:
    image1:
        image: image1
        docker:
            useCli: true
    image2:
        image: image2
        docker:
            useCli: true

[d-enk]

This is by design to prevent unexpectedly adding config where it doesn't exist.

And if no one has it, then add it to everyone?