[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
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.
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.
This PR:
* provides a code generator that converts
kustomize Go plugins to normal code, i.e.
the plugin appears as
t := builtin.NewImageTagTransformer()
instead of
p := plugin.Open("imagetagtransformer.so")
s := p.Lookup(someSymbol)
t, ok = s.(Transformer)
* converts the main processing thread in
kusttarget.go to use those factory calls to run
builtin generators and transformer before
calling user-supplied plugins,
* as an example, provides an imagetag transformer
plugin, converting a legacy transformer to
builtin plugin form with its own isolated test.
This test can be expanded by moving more code
into it, but that can be done in a later PR.
Writing core functionality as plugins assures a
maintained plugin authoring and testing framework,
assures modularity, provides meaningful plugin
examples, and gives us a means to make informed
choices on which kustomize packages to publish
(and which to move to internal/). The code
generator allows all this without losing "go get
sigs.k8s.io/kustomize" functionality.
TODO:
1) Convert remaining legacy transformers to
plugins (patch SMP/JSON, name prefix/suffix,
labels/annos) with their own tests. The
generators are already done; this PR wires
them up, and all tests & examples pass.
2) Push code down into the plugins, as the first
pass at conversion writes plugins as thin
layers over calls into code under the mess
that is pkg/. Once this is done, we can
reasonably move all the packages that aren't
imported by plugins to internal/.
This PR could be split in two, one to merge the
the generator, and the second to merge the
ImageTagTransformer plugin and its wiring into the
main flow.
The latter PR could then serve as an example for
converting the remaining transformers.
