[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.
- In ResMap, drop concept of internal Id to Resource
map. The ResMap is now (just) a list, allowing only
very particular edits.
- Resources should now be maintained in the order
loaded. A later PR can adjust tests to remove the
internal legacy sorting, and confirm order-out is
predictable from order-in. The PR would suppress
the sort in tests, and reorder the output to make
all tests pass again, and confirm that the new order
matched depth-first input traversal. The FromMap
fixture function was removed from all test inputs to
establish a predictable input order.
- Resources now have two 'Ids', OriginalId and
CurrentId. The former is fixed as
GVK-name-namespace at load time, the latter changes
during transformations. The latter can be used to
narrow name references when the former maps to
multiple resources. We allow bases to be loaded
more than once in a build (a diamond pattern), so
the OriginalId is not unique across the resources
set. The CurrentId is (and must be) unique, but is
constantly mutating. Failing to make this
distinction clear, and attempting to maintain a
mapping from a single mutating Id to a resource was
making the code too complex.
- Drop prefix/suffix from ResId - the ResId is now
immutable. A later PR can remove the distinction
with ItemId.
- This PR increases coverage of ResMap is since this
is a large refactor. Higher level tests didn't need
much change outside reordering of results at the
resource level.
