When merging resources such as the output of a `configMapGenerator`,
we need to consider the `CurrentId`, otherwise, we cannot extend
a common base definition twice by adding different prefixes, and
then further kustomize them.
See #1442.
[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.
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
