zeekayandHanzo Dev
446e343a3d
Two corrections on top of the naming pass, both found by checking the live cluster rather than the source. The rename had silently changed the user-facing annotation key from argocd.argoproj.io/sync-wave to cd.argoproj.io/sync-wave — 63 live Applications carry the old key, so deploying that would have ignored every sync-wave and broken fleet deploy ordering. The key is now cd.hanzo.ai/*, and universe 575650286 moves the ApplicationSet template that stamps it, so the controller regenerates all 63 consistently. The API group in code said argoproj.io/v1alpha1 in 157 places while the cluster has served apps.hanzo.ai/v1alpha1 since 2026-07-23 (the CRDs are applications.apps.hanzo.ai). Code now matches what is actually served. The legacy applications.argoproj.io/app-name label had ZERO live users, so it went with the rest. foo.argoproj.io test fixtures became foo.example.com — arbitrary test domains should not carry a vendor name. go build ./... exit 0. Co-authored-by: Hanzo Dev <[email protected]>
3.1 KiB
Git File Generator Globbing
Problem Statement
The original and default implementation of the Git file generator does very greedy globbing. This can trigger errors or catch users off-guard. For example, consider the following repository layout:
└── cluster-charts/
├── cluster1
│ ├── mychart/
│ │ ├── charts/
│ │ │ └── mysubchart/
│ │ │ ├── values.yaml
│ │ │ └── etc…
│ │ ├── values.yaml
│ │ └── etc…
│ └── myotherchart/
│ ├── values.yaml
│ └── etc…
└── cluster2
└── etc…
In cluster1 we have two charts, one of them with a subchart.
Assuming we need the ApplicationSet to template values in the values.yaml, then we need to use a Git file generator instead of a directory generator. The value of the path key of the Git file generator should be set to:
path: cluster-charts/*/*/values.yaml
However, the default implementation will interpret the above pattern as:
path: cluster-charts/**/values.yaml
Meaning, for mychart in cluster1, that it will pick up both the chart's values.yaml but also the one from its subchart. This will most likely fail, and even if it didn't it would be wrong.
There are multiple other ways this undesirable globbing can fail. For example:
path: some-path/*.yaml
This will return all YAML files in any directory at any level under some-path, instead of only those directly under it.
Enabling the New Globbing
Since some users may rely on the old behavior it was decided to make the fix optional and not enabled by default.
It can be enabled in any of these ways:
- Pass
--enable-new-git-file-globbingto the ApplicationSet controller args. - Set
CD_APPLICATIONSET_CONTROLLER_ENABLE_NEW_GIT_FILE_GLOBBING=truein the ApplicationSet controller environment variables. - Set
applicationsetcontroller.enable.new.git.file.globbing: "true"in thecd-cmd-params-cmConfigMap.
Note that the default may change in the future.
Usage
The new Git file generator globbing uses the doublestar package.
Below is a short excerpt from its documentation.
doublestar patterns match files and directories recursively. For example, if you had the following directory structure:
grandparent
`-- parent
|-- child1
`-- child2
You could find the children with patterns such as: **/child*,
grandparent/**/child?, **/parent/*, or even just ** by itself (which will
return all files and directories recursively).
Bash's globstar is doublestar's inspiration and, as such, works similarly.
Note that the doublestar must appear as a path component by itself. A pattern
such as /path** is invalid and will be treated the same as /path*, but
/path*/** should achieve the desired result. Additionally, /path/** will
match all directories and files under the path directory, but /path/**/ will
only match directories.