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.
* use one place to build plugin file names,
* use one loader instance,
* test for plugin enabled flag in just one place to
avoid errors and reduce if statements,
* don't return private objects,
* factor goplugin loading to a method,
* fix a related test that was commented out.
Do a longstanding TODO to remove kustomizationerror.
It wasn't used much, and it wasn't used consistently,
because it's complicated to decided when it's worth
proceeding to accumulate errors when one already knows
that one has a fatal error in the kustomization. Its
use was blocking refactoring for simplicity and making
tests harder to write.
Removing it lets us reinstate the cyclomatic complexity
check in KustTarget.
Also added more info to the affected error messages.
