mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-06-13 10:00:56 +00:00
Modify tests to present expected data in unsorted order.
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
This commit is contained in:
Jeffrey Regan
BIN
docs/images/sorted.png
Normal file
BIN
docs/images/sorted.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
114
docs/v_2.1.0.md
114
docs/v_2.1.0.md
@@ -6,6 +6,7 @@
|
||||
[imgModules]: images/goModules.png
|
||||
[imgPlugins]: images/plugins.png
|
||||
[imgPruning]: images/pruning.png
|
||||
[imgSorted]: images/sorted.png
|
||||
[imgWheels]: images/abandonedTrainingWheels.png
|
||||
[kustomization]: glossary.md#kustomization
|
||||
[_kustomization_]: glossary.md#kustomization
|
||||
@@ -25,8 +26,6 @@ _Summary_: Go modules, inventory, plugins, eased
|
||||
loading restrictions, and about ~80 issues closed
|
||||
since [v2.0.3] (over 300 commits).
|
||||
|
||||
|
||||
|
||||
## Go modules
|
||||
|
||||
![gopher with boxes][imgModules]
|
||||
@@ -38,23 +37,27 @@ as one or more [Go modules] for use in other
|
||||
programs (kubectl, kubebuilder, etc.) and in
|
||||
kustomize plugins (see below).
|
||||
|
||||
## Resource ordering
|
||||
|
||||
## Inventory generation for pruning
|
||||
![sort order retained][imgSorted]
|
||||
|
||||
![pruning dead branches][imgPruning]
|
||||
Kustomize now retains the depth-first order of
|
||||
resources as read.
|
||||
|
||||
Users can add an `inventory` stanza to their
|
||||
kustomization file, to add a special _inventory
|
||||
object_ to the `build` result.
|
||||
The `build` command now accepts a `--reorder`
|
||||
flag with values `legacy` and `none`,
|
||||
with a default value of `legacy`.
|
||||
|
||||
This object applies to the cluster along with
|
||||
everything else in the build result and can be
|
||||
used by other clients to intelligently _prune_
|
||||
orphaned cluster resources.
|
||||
|
||||
For more information see the
|
||||
[kustomize inventory object documentation].
|
||||
`legacy` means apply an ordering based on
|
||||
GVK, that currently emits `Namespace` objects
|
||||
first, and `ValidatingWebhookConfiguration`
|
||||
objects last.
|
||||
|
||||
`none` means do not reorder the resources before
|
||||
output. This means kustomize respects the input
|
||||
order of the data, giving the user a means to
|
||||
control output order. Generated resources always
|
||||
come last.
|
||||
|
||||
## Generator and transformer plugins
|
||||
|
||||
@@ -82,7 +85,7 @@ requests for kustomize revolve around changing the
|
||||
behavior of the builtin generators and
|
||||
transformers.
|
||||
|
||||
[v2.1.0] adds a _alpha_ plugin framework, that
|
||||
[v2.1.0] adds an _alpha_ plugin framework, that
|
||||
encourages users to write their own generators or
|
||||
transformers, _declaring them as kubernetes
|
||||
objects just like everything else_, and apply them
|
||||
@@ -93,7 +96,7 @@ confirm that the plugin framework can offer plugin
|
||||
authors the same capabilities as builtin
|
||||
operations, all the builtin generators and
|
||||
tranformers have been converted to plugin form
|
||||
(with a few exceptions awaiting Go module
|
||||
(with one exceptions awaiting Go module
|
||||
refinements). This means that adding, say, a
|
||||
`secretGenerator` or `commonAnnotations` directive
|
||||
to your kustomization will (in [v2.1.0]) trigger
|
||||
@@ -126,34 +129,79 @@ patch file. To share _resources_, use a relative
|
||||
path or URL to a kustomization directory in the
|
||||
`resources` directive.
|
||||
|
||||
## Inventory generation for pruning
|
||||
|
||||
![pruning dead branches][imgPruning]
|
||||
|
||||
_Alpha_
|
||||
|
||||
Users can add an `inventory` stanza to their
|
||||
kustomization file, to add a special _inventory
|
||||
object_ to the `build` result.
|
||||
|
||||
This object applies to the cluster along with
|
||||
everything else in the build result and can be
|
||||
used by other clients to intelligently _prune_
|
||||
orphaned cluster resources.
|
||||
|
||||
For more information see the
|
||||
[kustomize inventory object documentation].
|
||||
|
||||
|
||||
## Field changes / deprecations
|
||||
|
||||
* Generalized `resources` field.
|
||||
|
||||
The `resources` field has been generalized, and
|
||||
can now accept what formerly could only
|
||||
be specified in the `bases` field.
|
||||
The `resources` field has been generalized; it
|
||||
now accepts what formerly could only be
|
||||
specified in the `bases` field.
|
||||
|
||||
This change was made so that the `resources`,
|
||||
`generators` and `transformers` fields all
|
||||
accept the same argument format.
|
||||
|
||||
Each field's argument is a _string list_, where
|
||||
each entry is either a _resource_ (a relative
|
||||
path to a YAML file) or a [_kustomization_] (a
|
||||
relative path or URL pointing to a directory
|
||||
with a kustomization file). A kustomization
|
||||
directory used in this context is called a
|
||||
[_base_].
|
||||
> Each field's argument is a _string list_,
|
||||
> where each entry is either a _resource_ (a
|
||||
> relative path to a YAML file) or a
|
||||
> [_kustomization_] (a relative path or URL
|
||||
> pointing to a directory with a kustomization
|
||||
> file). A kustomization directory used in this
|
||||
> context is called a [_base_].
|
||||
|
||||
The `bases` field still works, but is no longer
|
||||
necessary, and will likely be deprecated in the
|
||||
next release. The _base_ as a concept is as
|
||||
important as ever, it's just that two new fields
|
||||
(`generators` and `tranformers`) and one existing
|
||||
field (`resources`) now accept arguments
|
||||
that were once accepted only by `bases`.
|
||||
The `bases` field still works, but is
|
||||
deprecated. Deal with this by simply moving the
|
||||
arguments of the `bases` field to the
|
||||
`resources` field in the desired order, e.g.
|
||||
|
||||
> ```
|
||||
> resources:
|
||||
> - someResouceFile.yaml
|
||||
> - someOtherResourceFile.yaml
|
||||
> bases:
|
||||
> - ../../someBaseDir
|
||||
> ```
|
||||
|
||||
could become
|
||||
|
||||
> ```
|
||||
> resources:
|
||||
> - someResouceFile.yaml
|
||||
> - ../../someBaseDir
|
||||
> - someOtherResourceFile.yaml
|
||||
> ```
|
||||
|
||||
The depth-first traversal order of items in the
|
||||
`resources:` field is respected by
|
||||
kustomize, allowing one to, say, process
|
||||
`someBaseDir` between the two resource files.
|
||||
See this discussion of
|
||||
[the `build --reorder` flag](#resource-ordering).
|
||||
|
||||
The _base_ as a concept is as important as ever,
|
||||
it's just that two new fields (`generators` and
|
||||
`tranformers`) and one existing field
|
||||
(`resources`) now accept arguments that were
|
||||
once accepted only by `bases`.
|
||||
|
||||
The fact that the `generators` and
|
||||
`transformers` field accept [bases]
|
||||
|
||||
Reference in New Issue
Block a user