- Attempt to account, at build time, for subsequent kubectl apply behavior.
(empty or no namespace means default).
- Account for the fact that not all objects have a namespace.
- Add new Equal method to ResId address merge name conflict
- Add GroupByName to resources by namespaces to resolve filenames conflict
- Added corresponding unit tests.
- Change the fail test for issue #1155
[doc]: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
Per this Go modules [doc] a repo or branch that's
already tagged v2 or higher should increment the major
version (e.g. go to v3) when releasing their first Go
module-based packages.
At the moment, the kustomize repo has these top level
packages in the sigs.k8s.io/kustomize module:
- `cmd` - holds main program for kustomize
Conceivably someone can depend on this
package for integration tests.
- `internal` - intentionally unreleased subpackages
- `k8sdeps` - an adapter wrapping k8s dependencies
This exists only for use in pre-Go-modules kustomize-into-kubectl
integration and won't live much longer (as everything involved is
switching to Go modules).
- `pkg` - kustomize packages for export
This should shrink in later versions, since
the surface area is too large, containing
sub-packages that should be in 'internal'.
- `plugin` - holds main programs for plugins
This PR changes the top level go.mod file from
```
module sigs.k8s.io/kustomize
```
to
```
module sigs.k8s.io/kustomize/v3
```
and adjusts all import statements to
reflect the change.
* Added support for arbitrary data types rather than just strings
* Added support for integer index-able arrays
* Improve code coverage for kunstruct
- kunstruct around 90%
- helper at 100%
* Update expansion.Expand method to preserve the original type of the variable
* Ensure the int field such .spec.replicas can be used
as a source in a first Deployment or as destination of a variable (in the
second Deployment variable).
Modify all `build` tests to use the raw,
non-sorted output of build. This makes every test
provide coverage for how kustomize re-orders (or
doesn't reorder) resources during processing.
Going forward, the ordering of resources in
_expected_ output should match the depth-first
ordering specified in the `resources:` field used
in the test's kustomization file.
The only exception to this rule would be tests
that actually confirmed some other output
ordering, e.g. the test of the
`LegacyOrderTransformer` plugin.
Fixes#756
Related #821
The previous implementation had a bug and poorly handled
types that should not have a `spec: replica:` field.
Documentation is updated to reflect the change in behavior,
and better highlights the cases where a patch should be
used instead of this shorthand.
