This is the last commit in yaml.v3 before
ae27a74434
which changed the indentation of sequence.
That change has has large downstream impact on tests in the kustomize
repo. To upgrade beyond this point in yaml.v3 means many changes to
indentation in "expected" values in tests. That should be done in a
PR dedicated to that purpose, after specific consideration the change.
ALLOW_MODULE_SPAN
This PR
- defines a patch conflict detector interface,
- extracts implementations of the interface from the
merginator code, making the merginator code
independent of --enable_kyaml.
- injects those implementations into kustomize
as a function of --enable_kyaml.
So, instead of using different merginators to combine
resmaps, this pr allows the use of a single patch merge
code path that uses different conflict detectors.
So instead of debating how to merge, we're now only
considering whether to warn on conflict detection
in one transformer.
This PR is in service of #3304, eliminating seven
instances where --enable_kyaml was consulted. These
were cases where conflict detection wasn't an issue
(but merging patches was).
[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.
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.
