Test examples against HEAD as well as against latest release.

2026-05-17 10:15:22 +00:00 · 2019-08-20 13:51:45 -07:00
parent 2b6a406dc7
commit 423a8a6e0d
26 changed files with 244 additions and 223 deletions
--- a/docs/INSTALL.md
+++ b/docs/INSTALL.md
@@ -25,7 +25,7 @@ chmod u+x kustomize

 Requires [Go] v1.12 or higher:

-<!-- @installkustomize @test -->
+<!-- @installkustomize @testAgainstLatestRelease -->
 ```
 go install sigs.k8s.io/kustomize/v3/cmd/kustomize
 ```
--- a/docs/zh/INSTALL.md
+++ b/docs/zh/INSTALL.md
@@ -33,7 +33,7 @@ chmod u+x kustomize

 使用 [Go] v1.10.1 或更高版本安装（如果可以访问 [golang.org]）：

-<!-- @installkustomize @test -->
+<!-- @installkustomize @testAgainstLatestRelease -->
 ```
 go install sigs.k8s.io/kustomize/v3/cmd/kustomize
 ```
--- a/examples/README.md
+++ b/examples/README.md
@@ -2,15 +2,11 @@ English | [简体中文](zh/README.md)

 # Examples

-These examples assume that `kustomize` is on your `$PATH`.
+To run these examples, your `$PATH` must contain `kustomize`.
+See the [installation instructions](../docs/INSTALL.md).

-They are covered by [pre-commit](../travis/pre-commit.sh)
-tests, and should work with HEAD
-
-<!-- @installkustomize @test -->
-```
-go get sigs.k8s.io/kustomize/v3/cmd/kustomize
-```
+These examples are [tested](../travis/pre-commit.sh)
+to work with the latest _released_ version of kustomize.

 Basic Usage

@@ -71,4 +67,4 @@ Multi Variant Examples
  * [breakfast](breakfast.md) - Customize breakfast for
     Alice and Bob.
     
-  * [multibases](multibases/README.md) - Composing three variants (dev, staging, production) with a common base.  
+  * [multibases](multibases/README.md) - Composing three variants (dev, staging, production) with a common base.  
--- a/examples/breakfast.md
+++ b/examples/breakfast.md
@@ -6,14 +6,14 @@

 Define a place to work:

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```

 Make a place to put the base breakfast configuration:

-<!-- @baseDir @test -->
+<!-- @baseDir @testAgainstLatestRelease -->
 ```
 mkdir -p $DEMO_HOME/breakfast/base
 ```
@@ -21,7 +21,7 @@ mkdir -p $DEMO_HOME/breakfast/base
 Make a `kustomization` to define what goes into
 breakfast.  This breakfast has coffee and pancakes:

-<!-- @baseKustomization @test -->
+<!-- @baseKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/breakfast/base/kustomization.yaml
 resources:
@@ -34,7 +34,7 @@ Here's a _coffee_ type.  Give it a `kind` and `metdata/name` field
 to conform to [kubernetes API object style]; no other
 file or definition is needed:

-<!-- @coffee @test -->
+<!-- @coffee @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/breakfast/base/coffee.yaml
 kind: Coffee
@@ -50,7 +50,7 @@ The `name` field merely distinguishes this instance of
 coffee from others (if there were any).

 Likewise, define _pancakes_:
-<!-- @pancakes @test -->
+<!-- @pancakes @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/breakfast/base/pancakes.yaml
 kind: Pancakes
@@ -64,7 +64,7 @@ EOF
 Make a custom [variant] of breakfast for Alice, who
 likes her coffee hot:

-<!-- @aliceOverlay @test -->
+<!-- @aliceOverlay @testAgainstLatestRelease -->
 ```
 mkdir -p $DEMO_HOME/breakfast/overlays/alice

@@ -87,7 +87,7 @@ EOF

 And likewise a [variant] for Bob, who wants _five_ pancakes, with strawberries:

-<!-- @bobOverlay @test -->
+<!-- @bobOverlay @testAgainstLatestRelease -->
 ```
 mkdir -p $DEMO_HOME/breakfast/overlays/bob

@@ -111,14 +111,14 @@ EOF

 One can now generate the configs for Alice’s breakfast:

-<!-- @generateAlice @test -->
+<!-- @generateAlice @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME/breakfast/overlays/alice
 ```

 Likewise for Bob:

-<!-- @generateBob @test -->
+<!-- @generateBob @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME/breakfast/overlays/bob
 ```
--- a/examples/combineConfigs.md
+++ b/examples/combineConfigs.md
@@ -128,7 +128,7 @@ defined in the [helloworld] demo.

 It will all live in this work directory:

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -139,7 +139,7 @@ DEMO_HOME=$(mktemp -d)

 Make a place to put the base configuration:

-<!-- @baseDir @test -->
+<!-- @baseDir @testAgainstLatestRelease -->
 ```
 mkdir -p $DEMO_HOME/base
 ```
@@ -150,7 +150,7 @@ environments. Here we're only defining a java
 properties file, and a `kustomization` file that
 references it.

-<!-- @baseKustomization @test -->
+<!-- @baseKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/base/common.properties
 color=blue
@@ -171,14 +171,14 @@ EOF
 Make an abbreviation for the parent of the overlay
 directories:

-<!-- @overlays @test -->
+<!-- @overlays @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 ```

 Create the files that define the _development_ overlay:

-<!-- @developmentFiles @test -->
+<!-- @developmentFiles @testAgainstLatestRelease -->
 ```
 mkdir -p $OVERLAYS/development

@@ -206,7 +206,7 @@ EOF

 One can now generate the configMaps for development:

-<!-- @runDev @test -->
+<!-- @runDev @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/development
 ```
@@ -260,7 +260,7 @@ deletes unused configMaps.
 Next, create the files for the _production_ overlay:


-<!-- @productionFiles @test -->
+<!-- @productionFiles @testAgainstLatestRelease -->
 ```
 mkdir -p $OVERLAYS/production

@@ -287,7 +287,7 @@ EOF

 One can now generate the configMaps for production:

-<!-- @runProd @test -->
+<!-- @runProd @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/production
 ```
--- a/examples/configGeneration.md
+++ b/examples/configGeneration.md
@@ -26,7 +26,7 @@ In this demo, the same [hello_world](helloWorld/README.md) is used while the Con
 ### Establish base and staging

 Establish the base with a configMapGenerator
-<!-- @establishBase @test -->
+<!-- @establishBase @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)

@@ -53,7 +53,7 @@ EOF
 ```

 Establish the staging with a patch applied to the ConfigMap
-<!-- @establishStaging @test -->
+<!-- @establishStaging @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -91,7 +91,7 @@ configured with data from a configMap.
 The deployment refers to this map by name:


-<!-- @showDeployment @test -->
+<!-- @showDeployment @testAgainstLatestRelease -->
 ```
 grep -C 2 configMapKeyRef $BASE/deployment.yaml
 ```
@@ -117,7 +117,7 @@ collected](https://github.com/kubernetes-sigs/kustomize/issues/242).

 The _staging_ [variant] here has a configMap [patch]:

-<!-- @showMapPatch @test -->
+<!-- @showMapPatch @testAgainstLatestRelease -->
 ```
 cat $OVERLAYS/staging/map.yaml
 ```
@@ -128,7 +128,7 @@ resource spec.

 The ConfigMap it modifies is declared from a configMapGenerator.

-<!-- @showMapBase @test -->
+<!-- @showMapBase @testAgainstLatestRelease -->
 ```
 grep -C 4 configMapGenerator $BASE/kustomization.yaml
 ```
@@ -141,7 +141,7 @@ _not_ what gets used in the cluster.  By design,
 kustomize modifies names of ConfigMaps declared from ConfigMapGenerator.  To see the names
 ultimately used in the cluster, just run kustomize:

-<!-- @grepStagingName @test -->
+<!-- @grepStagingName @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging |\
    grep -B 8 -A 1 staging-the-map
@@ -159,7 +159,7 @@ The suffix to the configMap name is generated from a
 hash of the maps content - in this case the name suffix
 is _k25m8k5k5m_:

-<!-- @grepStagingHash @test -->
+<!-- @grepStagingHash @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging | grep k25m8k5k5m
 ```
@@ -167,7 +167,7 @@ kustomize build $OVERLAYS/staging | grep k25m8k5k5m
 Now modify the map patch, to change the greeting
 the server will use:

-<!-- @changeMap @test -->
+<!-- @changeMap @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
 ```
@@ -181,7 +181,7 @@ kustomize build $OVERLAYS/staging |\

 Run kustomize again to see the new configMap names:

-<!-- @grepStagingName @test -->
+<!-- @grepStagingName @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging |\
    grep -B 8 -A 1 staging-the-map
@@ -192,7 +192,7 @@ in three new names ending in _cd7kdh48fd_ - one in the
 configMap name itself, and two in the deployment that
 uses the map:

-<!-- @countHashes @test -->
+<!-- @countHashes @testAgainstLatestRelease -->
 ```
 test 3 == \
  $(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \
--- a/examples/generatorOptions.md
+++ b/examples/generatorOptions.md
@@ -13,7 +13,7 @@ DEMO_HOME=$(mktemp -d)

 Create a kustomization and add a ConfigMap generator to it.

-<!-- @createCMGenerator @test -->
+<!-- @createCMGenerator @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/kustomization.yaml << EOF
 configMapGenerator:
@@ -25,7 +25,7 @@ EOF
 ```

 Add following generatorOptions
-<!-- @addGeneratorOptions @test -->
+<!-- @addGeneratorOptions @testAgainstLatestRelease -->
 ```
 cat >> $DEMO_HOME/kustomization.yaml << EOF
 generatorOptions:
@@ -39,7 +39,7 @@ EOF
 Run `kustomize build` and make sure that the generated ConfigMap
 
 - doesn't have name suffix
-    <!-- @verify @test -->
+    <!-- @verify @testAgainstLatestRelease -->
    ```
    test 1 == \
    $(kustomize build $DEMO_HOME | grep "name: my-configmap$" | wc -l); \
--- a/examples/helloWorld/README.md
+++ b/examples/helloWorld/README.md
@@ -22,7 +22,7 @@ Steps:

 First define a place to work:

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -44,7 +44,7 @@ To keep this document shorter, the base resources are
 off in a supplemental data directory rather than
 declared here as HERE documents.  Download them:

-<!-- @downloadBase @test -->
+<!-- @downloadBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir -p $BASE
@@ -57,7 +57,7 @@ curl -s -o "$BASE/#1.yaml" "https://raw.githubusercontent.com\

 Look at the directory:

-<!-- @runTree @test -->
+<!-- @runTree @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -88,7 +88,7 @@ would only recognize the resource files.

 The `base` directory has a [kustomization] file:

-<!-- @showKustomization @test -->
+<!-- @showKustomization @testAgainstLatestRelease -->
 ```
 more $BASE/kustomization.yaml
 ```
@@ -96,7 +96,7 @@ more $BASE/kustomization.yaml
 Optionally, run `kustomize` on the base to emit
 customized resources to `stdout`:

-<!-- @buildBase @test -->
+<!-- @buildBase @testAgainstLatestRelease -->
 ```
 kustomize build $BASE
 ```
@@ -106,14 +106,14 @@ kustomize build $BASE
 A first customization step could be to change the _app
 label_ applied to all resources:

-<!-- @addLabel @test -->
+<!-- @addLabel @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/app: hello/app: my-hello/' \
    $BASE/kustomization.yaml
 ```

 See the effect:
-<!-- @checkLabel @test -->
+<!-- @checkLabel @testAgainstLatestRelease -->
 ```
 kustomize build $BASE | grep -C 3 app:
 ```
@@ -127,7 +127,7 @@ Create a _staging_ and _production_ [overlay]:
 * Web server greetings from these cluster
   [variants] will differ from each other.

-<!-- @overlayDirectories @test -->
+<!-- @overlayDirectories @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -139,7 +139,7 @@ mkdir -p $OVERLAYS/production
 In the `staging` directory, make a kustomization
 defining a new name prefix, and some different labels.

-<!-- @makeStagingKustomization @test -->
+<!-- @makeStagingKustomization @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml
 namePrefix: staging-
@@ -162,7 +162,7 @@ greeting from _Good Morning!_ to _Have a pineapple!_

 Also, enable the _risky_ flag.

-<!-- @stagingMap @test -->
+<!-- @stagingMap @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/staging/map.yaml
 apiVersion: v1
@@ -180,7 +180,7 @@ EOF
 In the production directory, make a kustomization
 with a different name prefix and labels.

-<!-- @makeProductionKustomization @test -->
+<!-- @makeProductionKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/production/kustomization.yaml
 namePrefix: production-
@@ -202,7 +202,7 @@ EOF
 Make a production patch that increases the replica
 count (because production takes more traffic).

-<!-- @productionDeployment @test -->
+<!-- @productionDeployment @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/production/deployment.yaml
 apiVersion: apps/v1
@@ -228,7 +228,7 @@ EOF

 Review the directory structure and differences:

-<!-- @listFiles @test -->
+<!-- @listFiles @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -288,12 +288,12 @@ something like

 The individual resource sets are:

-<!-- @buildStaging @test -->
+<!-- @buildStaging @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging
 ```

-<!-- @buildProduction @test -->
+<!-- @buildProduction @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/production
 ```
--- a/examples/image.md
+++ b/examples/image.md
@@ -3,14 +3,14 @@

 Define a place to work:

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```

 Make a `kustomization` containing a pod resource

-<!-- @createKustomization @test -->
+<!-- @createKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/kustomization.yaml
 resources:
@@ -20,7 +20,7 @@ EOF

 Declare the pod resource

-<!-- @createDeployment @test -->
+<!-- @createDeployment @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/pod.yaml
 apiVersion: v1
@@ -46,7 +46,7 @@ The image `busybox` and tag `1.29.0` can be changed by adding `images` in `kusto


 Add `images`:
-<!-- @addImages @test -->
+<!-- @addImages @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 kustomize edit set image busybox=alpine:3.6
@@ -61,14 +61,14 @@ The following `images` will be added to `kustomization.yaml`:
 > ```

 Now build this `kustomization`
-<!-- @kustomizeBuild @test -->
+<!-- @kustomizeBuild @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME
 ```

 Confirm that this replaces _both_ busybox images and tags for `alpine:3.6`:

-<!-- @confirmImages @test -->
+<!-- @confirmImages @testAgainstLatestRelease -->
 ```
 test 2 = \
  $(kustomize build $DEMO_HOME | grep alpine:3.6 | wc -l); \
--- a/examples/jsonpatch.md
+++ b/examples/jsonpatch.md
@@ -6,7 +6,7 @@ The example below modifies an `Ingress` object with such a patch.

 Make a `kustomization` containing an ingress resource.

-<!-- @createIngress @test -->
+<!-- @createIngress @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)

@@ -36,7 +36,7 @@ Declare a JSON patch file to update two fields of the Ingress object:
 - change host from `foo.bar.com` to `foo.bar.io`
 - change servicePort from `80` to `8080`

-<!-- @addJsonPatch @test -->
+<!-- @addJsonPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/ingress_patch.json
 [
@@ -48,7 +48,7 @@ EOF

 You can also write the patch in YAML format. This example also shows the "add" operation:

-<!-- @addYamlPatch @test -->
+<!-- @addYamlPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/ingress_patch.yaml
 - op: replace
@@ -67,7 +67,7 @@ EOF

 Apply the patch by adding _patchesJson6902_ field in kustomization.yaml

-<!-- @applyJsonPatch @test -->
+<!-- @applyJsonPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patchesJson6902:
@@ -81,14 +81,14 @@ EOF
 ```

 Running `kustomize build $DEMO_HOME`, in the output confirm that host has been updated correctly.
-<!-- @confirmHost @test -->
+<!-- @confirmHost @testAgainstLatestRelease -->
 ```
 test 1 == \
  $(kustomize build $DEMO_HOME | grep "host: foo.bar.io" | wc -l); \
  echo $?
 ```
 Running `kustomize build $DEMO_HOME`, in the output confirm that the servicePort has been updated correctly.
-<!-- @confirmServicePort @test -->
+<!-- @confirmServicePort @testAgainstLatestRelease -->
 ```
 test 1 == \
  $(kustomize build $DEMO_HOME | grep "servicePort: 8080" | wc -l); \
@@ -97,7 +97,7 @@ test 1 == \

 If the patch is YAML-formatted, it will be parsed correctly:

-<!-- @applyYamlPatch @test -->
+<!-- @applyYamlPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patchesJson6902:
@@ -110,7 +110,7 @@ patchesJson6902:
 EOF
 ```

-<!-- @confirmYamlPatch @test -->
+<!-- @confirmYamlPatch @testAgainstLatestRelease -->
 ```
 test 1 == \
  $(kustomize build $DEMO_HOME | grep "path: /test" | wc -l); \
--- a/examples/ldap/README.md
+++ b/examples/ldap/README.md
@@ -18,7 +18,7 @@ Steps:

 First define a place to work:

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -38,7 +38,7 @@ To keep this document shorter, the base resources are
 off in a supplemental data directory rather than
 declared here as HERE documents.  Download them:

-<!-- @downloadBase @test -->
+<!-- @downloadBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir -p $BASE
@@ -53,7 +53,7 @@ curl -s -o "$BASE/#1" "$CONTENT/base\

 Look at the directory:

-<!-- @runTree @test -->
+<!-- @runTree @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -84,7 +84,7 @@ would only recognize the resource files.

 The `base` directory has a [kustomization] file:

-<!-- @showKustomization @test -->
+<!-- @showKustomization @testAgainstLatestRelease -->
 ```
 more $BASE/kustomization.yaml
 ```
@@ -92,7 +92,7 @@ more $BASE/kustomization.yaml
 Optionally, run `kustomize` on the base to emit
 customized resources to `stdout`:

-<!-- @buildBase @test -->
+<!-- @buildBase @testAgainstLatestRelease -->
 ```
 kustomize build $BASE
 ```
@@ -101,14 +101,14 @@ kustomize build $BASE

 A first customization step could be to set the name prefix to all resources:

-<!-- @namePrefix @test -->
+<!-- @namePrefix @testAgainstLatestRelease -->
 ```
 cd $BASE
 kustomize edit set nameprefix "my-"
 ```

 See the effect:
-<!-- @checkNameprefix @test -->
+<!-- @checkNameprefix @testAgainstLatestRelease -->
 ```
 kustomize build $BASE | grep -C 3 "my-"
 ```
@@ -121,7 +121,7 @@ Create a _staging_ and _production_ [overlay]:
 * _Production_ has a higher replica count and a persistent disk.
 * [variants] will differ from each other.

-<!-- @overlayDirectories @test -->
+<!-- @overlayDirectories @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -132,7 +132,7 @@ mkdir -p $OVERLAYS/production

 Download the staging customization and patch.

-<!-- @downloadStagingKustomization @test -->
+<!-- @downloadStagingKustomization @testAgainstLatestRelease -->
 ```
 curl -s -o "$OVERLAYS/staging/#1" "$CONTENT/overlays/staging\
 /{config.env,deployment.yaml,kustomization.yaml}"
@@ -159,7 +159,7 @@ as well as 2 replica
 #### Production Kustomization

 Download the production customization and patch.
-<!-- @downloadProductionKustomization @test -->
+<!-- @downloadProductionKustomization @testAgainstLatestRelease -->
 ```
 curl -s -o "$OVERLAYS/production/#1" "$CONTENT/overlays/production\
 /{deployment.yaml,kustomization.yaml}"
@@ -196,7 +196,7 @@ The production customization adds 6 replica as well as a consistent disk.

 Review the directory structure and differences:

-<!-- @listFiles @test -->
+<!-- @listFiles @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -258,12 +258,12 @@ The difference output should look something like

 The individual resource sets are:

-<!-- @buildStaging @test -->
+<!-- @buildStaging @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging
 ```

-<!-- @buildProduction @test -->
+<!-- @buildProduction @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/production
 ```
--- a/examples/multibases/README.md
+++ b/examples/multibases/README.md
@@ -20,13 +20,13 @@ that is just a single pod.

 Define a place to work:

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```

 Define a common base:
-<!-- @makeBase @test -->
+<!-- @makeBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir $BASE
@@ -51,7 +51,7 @@ EOF
 ```

 Define a dev variant overlaying base:
-<!-- @makeDev @test -->
+<!-- @makeDev @testAgainstLatestRelease -->
 ```
 DEV=$DEMO_HOME/dev
 mkdir $DEV
@@ -64,7 +64,7 @@ EOF
 ```

 Define a staging variant overlaying base:
-<!-- @makeStaging @test -->
+<!-- @makeStaging @testAgainstLatestRelease -->
 ```
 STAG=$DEMO_HOME/staging
 mkdir $STAG
@@ -77,7 +77,7 @@ EOF
 ```

 Define a production variant overlaying base:
-<!-- @makeProd @test -->
+<!-- @makeProd @testAgainstLatestRelease -->
 ```
 PROD=$DEMO_HOME/production
 mkdir $PROD
@@ -90,7 +90,7 @@ EOF
 ```

 Then define a _Kustomization_ composing three variants together:
-<!-- @makeTopLayer @test -->
+<!-- @makeTopLayer @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/kustomization.yaml
 resources:
@@ -119,7 +119,7 @@ Now the workspace has following directories

 Confirm that the `kustomize build` output contains three pod objects from dev, staging and production variants.

-<!-- @confirmVariants @test -->
+<!-- @confirmVariants @testAgainstLatestRelease -->
 ```
 test 1 == \
  $(kustomize build $DEMO_HOME | grep cluster-a-dev-myapp-pod | wc -l); \
--- a/examples/multibases/multi-namespace.md
+++ b/examples/multibases/multi-namespace.md
@@ -8,13 +8,13 @@ following demonstrates this using a base that's just one pod.

 Define a place to work:

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```

 Define a common base:
-<!-- @makeBase @test -->
+<!-- @makeBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir $BASE
@@ -39,7 +39,7 @@ EOF
 ```

 Define a variant in namespace-a overlaying base:
-<!-- @makeNamespaceA @test -->
+<!-- @makeNamespaceA @testAgainstLatestRelease -->
 ```
 NSA=$DEMO_HOME/namespace-a
 mkdir $NSA
@@ -60,7 +60,7 @@ EOF
 ```

 Define a variant in namespace-b overlaying base:
-<!-- @makeNamespaceB @test -->
+<!-- @makeNamespaceB @testAgainstLatestRelease -->
 ```
 NSB=$DEMO_HOME/namespace-b
 mkdir $NSB
@@ -81,7 +81,7 @@ EOF
 ```

 Then define a _Kustomization_ composing two variants together:
-<!-- @makeTopLayer @test -->
+<!-- @makeTopLayer @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/kustomization.yaml
 resources:
@@ -107,7 +107,7 @@ Now the workspace has following directories

 Confirm that the `kustomize build` output contains two pod objects from namespace-a and namespace-b.

-<!-- @confirmVariants @test -->
+<!-- @confirmVariants @testAgainstLatestRelease -->
 ```
 test 2 == \
  $(kustomize build $DEMO_HOME| grep -B 4 "namespace: namespace-[ab]" | grep "name: myapp-pod" | wc -l); \
--- a/examples/mySql/README.md
+++ b/examples/mySql/README.md
@@ -11,7 +11,7 @@ In the production environment we want:
 - MySQL to use persistent disk for storing data.

 First make a place to work:
-<!-- @makeDemoHome @test -->
+<!-- @makeDemoHome @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -25,7 +25,7 @@ as HERE documents.

 Download them:

-<!-- @downloadResources @test -->
+<!-- @downloadResources @testAgainstLatestRelease -->
 ```
 curl -s  -o "$DEMO_HOME/#1.yaml" "https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -40,14 +40,14 @@ a file called `kustomization.yaml`.

 Start this file:

-<!-- @kustomizeYaml @test -->
+<!-- @kustomizeYaml @testAgainstLatestRelease -->
 ```
 touch $DEMO_HOME/kustomization.yaml
 ```

 ### Add the resources

-<!-- @addResources @test -->
+<!-- @addResources @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME

@@ -73,7 +73,7 @@ Arrange for the MySQL resources to begin with prefix
 _prod-_ (since they are meant for the _production_
 environment):

-<!-- @customizeLabel @test -->
+<!-- @customizeLabel @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME

@@ -91,7 +91,7 @@ cat kustomization.yaml
 This `namePrefix` directive adds _prod-_ to all
 resource names.

-<!-- @genNamePrefixConfig @test -->
+<!-- @genNamePrefixConfig @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME
 ```
@@ -134,7 +134,7 @@ selector.
 `kustomize` does not have `edit set label` command to add
 a label, but one can always edit `kustomization.yaml` directly:

-<!-- @customizeLabels @test -->
+<!-- @customizeLabels @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/app: helloworld/app: prod/' \
    $DEMO_HOME/kustomization.yaml
@@ -153,7 +153,7 @@ environment. So we want to use Persistent Disk in
 production. kustomize lets you apply `patchesStrategicMerge` to the
 resources.

-<!-- @createPatchFile @test -->
+<!-- @createPatchFile @testAgainstLatestRelease -->
 ```
 cat <<'EOF' > $DEMO_HOME/persistent-disk.yaml
 apiVersion: apps/v1beta2 # for versions before 1.9.0 use apps/v1beta2
@@ -173,7 +173,7 @@ EOF

 Add the patch file to `kustomization.yaml`:

-<!-- @specifyPatch @test -->
+<!-- @specifyPatch @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >> $DEMO_HOME/kustomization.yaml
 patchesStrategicMerge:
@@ -199,7 +199,7 @@ The output of the following command can now be applied
 to the cluster (i.e. piped to `kubectl apply`) to
 create the production environment.

-<!-- @finalInflation @test -->
+<!-- @finalInflation @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME  # | kubectl apply -f -
 ```
--- a/examples/patchMultipleObjects.md
+++ b/examples/patchMultipleObjects.md
@@ -29,7 +29,7 @@ The example below shows how to inject a sidecar container for all deployment res

 Make a `kustomization` containing a Deployment resource.

-<!-- @createDeployment @test -->
+<!-- @createDeployment @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)

@@ -74,7 +74,7 @@ EOF

 Declare a Strategic Merge Patch file to inject a sidecar container:

-<!-- @addPatch @test -->
+<!-- @addPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/patch.yaml
 apiVersion: apps/v1
@@ -95,7 +95,7 @@ EOF

 Apply the patch by adding _patches_ field in kustomization.yaml

-<!-- @applyPatch @test -->
+<!-- @applyPatch @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patches:
@@ -107,7 +107,7 @@ EOF

 Running `kustomize build $DEMO_HOME`, in the output confirm that both Deployment resources are patched correctly.

-<!-- @confirmPatch @test -->
+<!-- @confirmPatch @testAgainstLatestRelease -->
 ```
 test 2 == \
  $(kustomize build $DEMO_HOME | grep "image: docker.io/istio/proxyv2" | wc -l); \
--- a/examples/remoteBuild.md
+++ b/examples/remoteBuild.md
@@ -11,7 +11,7 @@ To try this immediately, run a build against the kustomization
 in the [multibases](multibases/README.md) example.  There's
 one pod in the output:

-<!-- @remoteOverlayBuild @test -->
+<!-- @remoteOverlayBuild @testAgainstLatestRelease -->

 ```
 target="github.com/kubernetes-sigs/kustomize//examples/multibases/dev/?ref=v1.0.6"
@@ -24,7 +24,7 @@ Run against the overlay in that example to get three pods
 (the overlay combines the dev, staging and prod bases for
 someone who wants to send them all at the same time):

-<!-- @remoteBuild @test -->
+<!-- @remoteBuild @testAgainstLatestRelease -->
 ```
 target="https://github.com/kubernetes-sigs/kustomize//examples/multibases?ref=v1.0.6"
 test 3 == \
@@ -34,7 +34,7 @@ test 3 == \

 A base can be a URL:

-<!-- @createOverlay @test -->
+<!-- @createOverlay @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)

@@ -48,7 +48,7 @@ EOF
 Build this to confirm that all three pods from the base
 have the `remote-` prefix.

-<!-- @remoteBases @test -->
+<!-- @remoteBases @testAgainstLatestRelease -->
 ```
 test 3 == \
  $(kustomize build $DEMO_HOME | grep remote-.*-myapp-pod | wc -l); \
--- a/examples/secretGeneratorPlugin.md
+++ b/examples/secretGeneratorPlugin.md
@@ -25,7 +25,7 @@ etc.

 ## Make a place to work

-<!-- @establishBase @test -->
+<!-- @establishBase @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -43,7 +43,7 @@ Here's an example combining all three methods:

 Make an env file with some short secrets:

-<!-- @makeEnvFile @test -->
+<!-- @makeEnvFile @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/foo.env
 ROUTER_PASSWORD=admin
@@ -53,7 +53,7 @@ EOF

 Make a text file with a long secret:

-<!-- @makeLongSecretFile @test -->
+<!-- @makeLongSecretFile @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/longsecret.txt
 Lorem ipsum dolor sit amet,
@@ -67,7 +67,7 @@ And make a kustomization file referring to the
 above and _additionally_ defining some literal KV
 pairs in line:

-<!-- @makeKustomization1 @test -->
+<!-- @makeKustomization1 @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/kustomization.yaml
 secretGenerator:
@@ -84,7 +84,7 @@ EOF

 Now generate the Secret:

-<!-- @build1 @test -->
+<!-- @build1 @testAgainstLatestRelease -->
 ```
 result=$(kustomize build $DEMO_HOME)
 echo "$result"
@@ -141,7 +141,7 @@ from a database.

 Download it

-<!-- @copyPlugin @test -->
+<!-- @copyPlugin @testAgainstLatestRelease -->
 ```
 repo=https://raw.githubusercontent.com/kubernetes-sigs/kustomize
 pPath=plugin/someteam.example.com/v1/secretsfromdatabase
@@ -165,7 +165,7 @@ go build -buildmode plugin \

 Create a configuration file for it:

-<!-- @makeConfiguration @test -->
+<!-- @makeConfiguration @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/secretFromDb.yaml
 apiVersion: someteam.example.com/v1
@@ -183,7 +183,7 @@ EOF
 Create a new kustomization file
 referencing this plugin:

-<!-- @makeKustomization2 @test -->
+<!-- @makeKustomization2 @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/kustomization.yaml
 generators:
--- a/examples/springboot/README.md
+++ b/examples/springboot/README.md
@@ -13,7 +13,7 @@ In the production environment we want to customize the following:
 - health check and readiness check.

 First make a place to work:
-<!-- @makeDemoHome @test -->
+<!-- @makeDemoHome @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -27,7 +27,7 @@ as HERE documents.

 Download them:

-<!-- @downloadResources @test -->
+<!-- @downloadResources @testAgainstLatestRelease -->
 ```
 CONTENT="https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -44,14 +44,14 @@ a file called `kustomization.yaml`.

 Start this file:

-<!-- @kustomizeYaml @test -->
+<!-- @kustomizeYaml @testAgainstLatestRelease -->
 ```
 touch $DEMO_HOME/kustomization.yaml
 ```

 ### Add the resources

-<!-- @addResources @test -->
+<!-- @addResources @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME

@@ -71,7 +71,7 @@ cat kustomization.yaml

 ### Add configMap generator

-<!-- @addConfigMap @test -->
+<!-- @addConfigMap @testAgainstLatestRelease -->
 ```
 echo "app.name=Kustomize Demo" >$DEMO_HOME/application.properties

@@ -102,7 +102,7 @@ For Spring Boot application, we can set an active profile through the environmen
 the application will pick up an extra `application-<profile>.properties` file. With this, we can customize the configMap in two
 steps. Add an environment variable through the patch and add a file to the configMap.

-<!-- @customizeConfigMap @test -->
+<!-- @customizeConfigMap @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/patch.yaml
 apiVersion: apps/v1beta2
@@ -149,7 +149,7 @@ Arrange for the resources to begin with prefix
 _prod-_ (since they are meant for the _production_
 environment):

-<!-- @customizeLabel @test -->
+<!-- @customizeLabel @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 kustomize edit set nameprefix 'prod-'
@@ -165,7 +165,7 @@ This `namePrefix` directive adds _prod-_ to all
 resource names, as can be seen by building the
 resources:

-<!-- @build1 @test -->
+<!-- @build1 @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME | grep prod-
 ```
@@ -180,7 +180,7 @@ selector.
 add a label, but one can always edit
 `kustomization.yaml` directly:

-<!-- @customizeLabels @test -->
+<!-- @customizeLabels @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 commonLabels:
@@ -191,7 +191,7 @@ EOF
 Confirm that the resources now all have names prefixed
 by `prod-` and the label tuple `env:prod`:

-<!-- @build2 @test -->
+<!-- @build2 @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME | grep -C 3 env
 ```
@@ -205,7 +205,7 @@ set JVM options accordingly.

 Download the patch `memorylimit_patch.yaml`. It contains the memory limits setup.

-<!-- @downloadPatch @test -->
+<!-- @downloadPatch @testAgainstLatestRelease -->
 ```
 curl -s  -o "$DEMO_HOME/#1.yaml" \
  "$CONTENT/overlays/production/{memorylimit_patch}.yaml"
@@ -243,7 +243,7 @@ has end points such as `/actuator/health` for this. We can customize the k8s dep

 Download the patch `healthcheck_patch.yaml`. It contains the liveness probes and readyness probes.

-<!-- @downloadPatch @test -->
+<!-- @downloadPatch @testAgainstLatestRelease -->
 ```
 curl -s  -o "$DEMO_HOME/#1.yaml" \
  "$CONTENT/overlays/production/{healthcheck_patch}.yaml"
@@ -281,7 +281,7 @@ The output contains

 Add these patches to the kustomization:

-<!-- @addPatch @test -->
+<!-- @addPatch @testAgainstLatestRelease -->
 ```
 cd $DEMO_HOME
 kustomize edit add patch memorylimit_patch.yaml
@@ -301,7 +301,7 @@ The output of the following command can now be applied
 to the cluster (i.e. piped to `kubectl apply`) to
 create the production environment.

-<!-- @finalBuild @test -->
+<!-- @finalBuild @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME  # | kubectl apply -f -
 ```
--- a/examples/transformerconfigs/crd/README.md
+++ b/examples/transformerconfigs/crd/README.md
@@ -3,7 +3,7 @@
 This tutorial shows how to add transformer configurations to support a custom resource.

 Create a workspace by
-<!-- @createws @test -->
+<!-- @createws @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -17,7 +17,7 @@ Consider a CRD of kind `MyKind` with fields
 - `.spec.selectors` as the label selectors

 Add the following file to configure the transformers for the above fields
-<!-- @addConfig @test -->
+<!-- @addConfig @testAgainstLatestRelease -->
 ```
 mkdir $DEMO_HOME/kustomizeconfig
 cat > $DEMO_HOME/kustomizeconfig/mykind.yaml << EOF
@@ -51,7 +51,7 @@ EOF
 Create a file with some resources that
 includes an instance of `MyKind`:

-<!-- @createResource @test -->
+<!-- @createResource @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/resources.yaml << EOF
 apiVersion: v1
@@ -88,7 +88,7 @@ EOF

 Create a kustomization referring to it:

-<!-- @createKustomization @test -->
+<!-- @createKustomization @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/kustomization.yaml << EOF
 resources:
@@ -112,7 +112,7 @@ EOF

 Use the customized transformer configurations by specifying them
 in the kustomization file:
-<!-- @addTransformerConfigs @test -->
+<!-- @addTransformerConfigs @testAgainstLatestRelease -->
 ```
 cat >> $DEMO_HOME/kustomization.yaml << EOF
 configurations:
@@ -122,7 +122,7 @@ EOF

 Run `kustomize build` and verify that the namereference is correctly resolved.

-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 2 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*Ref" | grep "test-" | wc -l); \
@@ -131,7 +131,7 @@ echo $?

 Run `kustomize build` and verify that the vars correctly resolved.

-<!-- @verify @test -->
+<!-- @verify @testAgainstLatestRelease -->
 ```
 test 0 == \
 $(kustomize build $DEMO_HOME | grep "BEE_ACTION" | wc -l); \
--- a/examples/transformerconfigs/images/README.md
+++ b/examples/transformerconfigs/images/README.md
@@ -3,7 +3,7 @@
 This tutorial shows how to modify images in resources, and create a custom images transformer configuration.

 Create a workspace by
-<!-- @createws @test -->
+<!-- @createws @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -15,7 +15,7 @@ Consider a Custom Resource Definition(CRD) of kind `MyKind` with field

 Add the following file to configure the images transformer for the CRD:

-<!-- @addConfig @test -->
+<!-- @addConfig @testAgainstLatestRelease -->
 ```
 mkdir $DEMO_HOME/kustomizeconfig
 cat > $DEMO_HOME/kustomizeconfig/mykind.yaml << EOF
@@ -30,7 +30,7 @@ EOF

 Create a file with some resources that includes an instance of `MyKind`:

-<!-- @createResource @test -->
+<!-- @createResource @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/resources.yaml << EOF

@@ -66,7 +66,7 @@ EOF

 Create a kustomization.yaml referring to it:

-<!-- @createKustomization @test -->
+<!-- @createKustomization @testAgainstLatestRelease -->
 ```
 cat > $DEMO_HOME/kustomization.yaml << EOF
 resources:
@@ -90,7 +90,7 @@ EOF

 Use the customized transformer configurations by specifying them
 in the kustomization file:
-<!-- @addTransformerConfigs @test -->
+<!-- @addTransformerConfigs @testAgainstLatestRelease -->
 ```
 cat >> $DEMO_HOME/kustomization.yaml << EOF
 configurations:
@@ -100,27 +100,27 @@ EOF

 Run `kustomize build` and verify that the images have been updated.

-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 1 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "new-crd-image:new-v1-tag" | wc -l); \
 echo $?
 ```

-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 1 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "new-app-1:MYNEWTAG-1" | wc -l); \
 echo $?
 ```

-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 1 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "my-docker2@sha" | wc -l); \
 echo $?
 ```
-<!-- @build @test -->
+<!-- @build @testAgainstLatestRelease -->
 ```
 test 1 == \
 $(kustomize build $DEMO_HOME | grep -A 2 ".*image" | grep "prod-mysql:v3" | wc -l); \
--- a/examples/validationTransformer/README.md
+++ b/examples/validationTransformer/README.md
@@ -24,7 +24,7 @@ loaded by Kustomize.

 Make a place to work:

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 mkdir -p $DEMO_HOME/valid
@@ -38,7 +38,7 @@ mkdir -p $PLUGINDIR
 Download the [kubeval] binary depending on the operating system
 and add it to $PATH.

-<!-- @downloadKubeval @test -->
+<!-- @downloadKubeval @testAgainstLatestRelease -->
 ```
 OS=`uname | sed -e 's/Linux/linux/' -e 's/Darwin/darwin/'`
 wget https://github.com/instrumenta/kubeval/releases/download/0.9.2/kubeval-${OS}-amd64.tar.gz
@@ -60,7 +60,7 @@ A transformer plugin for the validation can be written as a
 bash script, which execute the [kubeval] binary and return proper
 output and exit code.

-<!-- @writePlugin @test -->
+<!-- @writePlugin @testAgainstLatestRelease -->
 ```
 cat <<'EOF' > $PLUGINDIR/Validator
 #!/bin/bash
@@ -95,7 +95,7 @@ chmod +x $PLUGINDIR/Validator
 Define a kustomization containing a valid ConfigMap
 and the transformer plugin.

-<!-- @writeKustomization @test -->
+<!-- @writeKustomization @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/valid/configmap.yaml
 apiVersion: v1
@@ -125,7 +125,7 @@ EOF
 Define a kustomization containing an invalid ConfigMap
 and the transformer plugin.

-<!-- @writeKustomization @test -->
+<!-- @writeKustomization @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$DEMO_HOME/invalid/configmap.yaml
 apiVersion: v1
@@ -175,7 +175,7 @@ The directory structure is as the following:
 Define a helper function to run kustomize with the
 correct environment and flags for plugins:

-<!-- @defineKustomizeBd @test -->
+<!-- @defineKustomizeBd @testAgainstLatestRelease -->
 ```
 function kustomizeBd {
  XDG_CONFIG_HOME=$DEMO_HOME \
@@ -187,7 +187,7 @@ function kustomizeBd {

 Build the valid variant

-<!-- @buildValid @test -->
+<!-- @buildValid @testAgainstLatestRelease -->
 ```
 kustomizeBd valid
 ```
@@ -215,7 +215,7 @@ data: Invalid type. Expected: object, given: array

 ## cleanup

-<!-- @cleanup @test -->
+<!-- @cleanup @testAgainstLatestRelease -->
 ```shell
 rm -rf $DEMO_HOME
 ```
--- a/examples/wordpress/README.md
+++ b/examples/wordpress/README.md
@@ -8,7 +8,7 @@ To run WordPress, it's necessary to
 - access the service name of MySQL database from WordPress container

 First make a place to work:
-<!-- @makeDemoHome @test -->
+<!-- @makeDemoHome @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 MYSQL_HOME=$DEMO_HOME/mysql
@@ -21,7 +21,7 @@ mkdir -p $WORDPRESS_HOME

 Download the resources and `kustomization.yaml` for WordPress.

-<!-- @downloadResources @test -->
+<!-- @downloadResources @testAgainstLatestRelease -->
 ```
 CONTENT="https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -33,7 +33,7 @@ curl -s -o "$WORDPRESS_HOME/#1.yaml" \

 Download the resources and `kustomization.yaml` for MySQL.

-<!-- @downloadResources @test -->
+<!-- @downloadResources @testAgainstLatestRelease -->
 ```
 CONTENT="https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -48,7 +48,7 @@ curl -s -o "$MYSQL_HOME/#1.yaml" \
 Create a new kustomization with two bases,
 `wordpress` and `mysql`:

-<!-- @createKustomization @test -->
+<!-- @createKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$DEMO_HOME/kustomization.yaml
 resources:
@@ -65,7 +65,7 @@ In the new kustomization, apply a patch for wordpress deployment. The patch does
 - Add an initial container to show the mysql service name
 - Add environment variable that allow wordpress to find the mysql database

-<!-- @downloadPatch @test -->
+<!-- @downloadPatch @testAgainstLatestRelease -->
 ```
 CONTENT="https://raw.githubusercontent.com\
 /kubernetes-sigs/kustomize\
@@ -105,7 +105,7 @@ $(WORDPRESS_SERVICE) and $(MYSQL_SERVICE).

 ### Bind the Variables to k8s Object Fields

-<!-- @addVarRef @test -->
+<!-- @addVarRef @testAgainstLatestRelease -->
 ```
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 vars:
@@ -128,7 +128,7 @@ EOF
 ### Substitution
 Confirm the variable substitution:

-<!-- @kustomizeBuild @test -->
+<!-- @kustomizeBuild @testAgainstLatestRelease -->
 ```
 kustomize build $DEMO_HOME
 ```
--- a/examples/zh/configGeneration.md
+++ b/examples/zh/configGeneration.md
@@ -30,7 +30,7 @@ kustomize 提供了两种添加 ConfigMap 的方法：
 ### 建立 base 和 staging

 使用 configMapGenerator 建立 base
-<!-- @establishBase @test -->
+<!-- @establishBase @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)

@@ -57,7 +57,7 @@ EOF
 ```

 通过应用 ConfigMap patch 的方式建立 staging
-<!-- @establishStaging @test -->
+<!-- @establishStaging @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -93,7 +93,7 @@ EOF

 deployment 按照名称引用此 ConfigMap ：

-<!-- @showDeployment @test -->
+<!-- @showDeployment @testAgainstLatestRelease -->
 ```
 grep -C 2 configMapKeyRef $BASE/deployment.yaml
 ```
@@ -111,7 +111,7 @@ grep -C 2 configMapKeyRef $BASE/deployment.yaml

 _staging_ 的 [variant] 包含一个 configMap 的 [patch]：

-<!-- @showMapPatch @test -->
+<!-- @showMapPatch @testAgainstLatestRelease -->
 ```
 cat $OVERLAYS/staging/map.yaml
 ```
@@ -120,7 +120,7 @@ cat $OVERLAYS/staging/map.yaml

 在 ConfigMapGenerator 中声明 ConfigMap 的修改。

-<!-- @showMapBase @test -->
+<!-- @showMapBase @testAgainstLatestRelease -->
 ```
 grep -C 4 configMapGenerator $BASE/kustomization.yaml
 ```
@@ -129,7 +129,7 @@ grep -C 4 configMapGenerator $BASE/kustomization.yaml

 但是，文件中指定的名称值不是群集中使用的名称值。根据设计，kustomize 修改从 ConfigMapGenerator 声明的 ConfigMaps 的名称。要查看最终在群集中使用的名称，只需运行 kustomize：

-<!-- @grepStagingName @test -->
+<!-- @grepStagingName @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging |\
    grep -B 8 -A 1 staging-the-map
@@ -141,14 +141,14 @@ kustomize build $OVERLAYS/staging |\

 configMap 名称的后缀是由 map 内容的哈希生成的 - 在这种情况下，名称后缀是 _k25m8k5k5m_ ：

-<!-- @grepStagingHash @test -->
+<!-- @grepStagingHash @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging | grep k25m8k5k5m
 ```

 现在修改 map patch ，更改该服务将使用的问候消息：

-<!-- @changeMap @test -->
+<!-- @changeMap @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
 ```
@@ -162,7 +162,7 @@ kustomize build $OVERLAYS/staging |\

 再次运行 kustomize 查看新的 configMap 名称：

-<!-- @grepStagingName @test -->
+<!-- @grepStagingName @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging |\
    grep -B 8 -A 1 staging-the-map
@@ -170,7 +170,7 @@ kustomize build $OVERLAYS/staging |\

 确认 configMap 内容的更改将会生成以 _cd7kdh48fd_ 结尾的三个新名称 - 一个在 configMap 的名称中，另两个在使用 ConfigMap 的 deployment 中：

-<!-- @countHashes @test -->
+<!-- @countHashes @testAgainstLatestRelease -->
 ```
 test 3 == \
  $(kustomize build $OVERLAYS/staging | grep cd7kdh48fd | wc -l); \
--- a/examples/zh/helloWorld.md
+++ b/examples/zh/helloWorld.md
@@ -21,7 +21,7 @@

 首先创建一个工作空间：

-<!-- @makeWorkplace @test -->
+<!-- @makeWorkplace @testAgainstLatestRelease -->
 ```
 DEMO_HOME=$(mktemp -d)
 ```
@@ -38,7 +38,7 @@ DEMO_HOME=$(mktemp -d)

 为了使本文档保持简洁，base 的资源位于补充目录中，并不在此处，请按照下面的方法下载它们：

-<!-- @downloadBase @test -->
+<!-- @downloadBase @testAgainstLatestRelease -->
 ```
 BASE=$DEMO_HOME/base
 mkdir -p $BASE
@@ -51,7 +51,7 @@ curl -s -o "$BASE/#1.yaml" "https://raw.githubusercontent.com\

 观察该目录：

-<!-- @runTree @test -->
+<!-- @runTree @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -80,14 +80,14 @@ tree $DEMO_HOME

 `base` 目录中包含一个 [kustomization] 文件：

-<!-- @showKustomization @test -->
+<!-- @showKustomization @testAgainstLatestRelease -->
 ```
 more $BASE/kustomization.yaml
 ```

 （可选）在 base 目录上运行 `kustomize` 将定制过的 resources 打印到标准输出：

-<!-- @buildBase @test -->
+<!-- @buildBase @testAgainstLatestRelease -->
 ```
 kustomize build $BASE
 ```
@@ -96,14 +96,14 @@ kustomize build $BASE

 定制 _app label_ 并应用于所有的 resources ：

-<!-- @addLabel @test -->
+<!-- @addLabel @testAgainstLatestRelease -->
 ```
 sed -i.bak 's/app: hello/app: my-hello/' \
    $BASE/kustomization.yaml
 ```

 查看效果：
-<!-- @checkLabel @test -->
+<!-- @checkLabel @testAgainstLatestRelease -->
 ```
 kustomize build $BASE | grep -C 3 app:
 ```
@@ -116,7 +116,7 @@ kustomize build $BASE | grep -C 3 app:
 * _Production_ 包含更多的副本数。
 * 来自这些集群 [variants] 的问候消息将与来自其他集群的不同。

-<!-- @overlayDirectories @test -->
+<!-- @overlayDirectories @testAgainstLatestRelease -->
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -127,7 +127,7 @@ mkdir -p $OVERLAYS/production

 在 `staging` 目录中创建一个 kustomization 文件，用来定义一个新的名称前缀和一些不同的 labels 。

-<!-- @makeStagingKustomization @test -->
+<!-- @makeStagingKustomization @testAgainstLatestRelease -->
 ```
 cat <<'EOF' >$OVERLAYS/staging/kustomization.yaml
 namePrefix: staging-
@@ -149,7 +149,7 @@ EOF

 同时，将 _risky_ 标记设置为 true 。

-<!-- @stagingMap @test -->
+<!-- @stagingMap @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/staging/map.yaml
 apiVersion: v1
@@ -166,7 +166,7 @@ EOF

 在 `production` 目录中创建一个 kustomization 文件，用来定义一个新的名称前缀和 labels 。

-<!-- @makeProductionKustomization @test -->
+<!-- @makeProductionKustomization @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/production/kustomization.yaml
 namePrefix: production-
@@ -187,7 +187,7 @@ EOF

 因为生产环境需要处理更多的流量，新建一个 production patch 来增加副本数。

-<!-- @productionDeployment @test -->
+<!-- @productionDeployment @testAgainstLatestRelease -->
 ```
 cat <<EOF >$OVERLAYS/production/deployment.yaml
 apiVersion: apps/v1
@@ -210,7 +210,7 @@ EOF

 查看目录结构和差异：

-<!-- @listFiles @test -->
+<!-- @listFiles @testAgainstLatestRelease -->
 ```
 tree $DEMO_HOME
 ```
@@ -268,12 +268,12 @@ diff \

 输出不同 _overlys_ 的配置：

-<!-- @buildStaging @test -->
+<!-- @buildStaging @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/staging
 ```

-<!-- @buildProduction @test -->
+<!-- @buildProduction @testAgainstLatestRelease -->
 ```
 kustomize build $OVERLAYS/production
 ```
--- a/examples/zh/jsonpatch.md
+++ b/examples/zh/jsonpatch.md
@@ -6,7 +6,7 @@ kustomization文件支持通过[JSON patches](https://tools.ietf.org/html/rfc690

 首先，创建一个包含`ingress`的`kustomization`文件.

-<!-- @createIngress @test -->
+<!-- @createIngress @testAgainstLatestRelease -->
 ```bash
 DEMO_HOME=$(mktemp -d)

@@ -36,7 +36,7 @@ EOF
 - 把 host 从 `foo.bar.com` 改为 `foo.bar.io`
 - 把 servicePort 从 `80` 改为 `8080`

-<!-- @addJsonPatch @test -->
+<!-- @addJsonPatch @testAgainstLatestRelease -->
 ```bash
 cat <<EOF >$DEMO_HOME/ingress_patch.json
 [
@@ -48,7 +48,7 @@ EOF

 JSON patch 也可以写成 YAML 的格式.该例子顺便展示了“添加”操作：

-<!-- @addYamlPatch @test -->
+<!-- @addYamlPatch @testAgainstLatestRelease -->
 ```bash
 cat <<EOF >$DEMO_HOME/ingress_patch.yaml
 - op: replace
@@ -67,7 +67,7 @@ EOF

 在kustomization.yaml文件中增加 _patchesJson6902_ 字段，以应用该补丁

-<!-- @applyJsonPatch @test -->
+<!-- @applyJsonPatch @testAgainstLatestRelease -->
 ```bash
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patchesJson6902:
@@ -82,7 +82,7 @@ EOF

 运行 `kustomize build $DEMO_HOME`, 在输出那里确认 host 已经被正确更新.

-<!-- @confirmHost @test -->
+<!-- @confirmHost @testAgainstLatestRelease -->
 ```bash
 test 1 == \
  $(kustomize build $DEMO_HOME | grep "host: foo.bar.io" | wc -l); \
@@ -91,7 +91,7 @@ test 1 == \

 运行 `kustomize build $DEMO_HOME`, 在输出那里确认 servicePort 已经被正确更新.

-<!-- @confirmServicePort @test -->
+<!-- @confirmServicePort @testAgainstLatestRelease -->

 ```bash
 test 1 == \
@@ -101,7 +101,7 @@ test 1 == \

 如果 patch 是YAML格式的，就能正确解析:

-<!-- @applyYamlPatch @test -->
+<!-- @applyYamlPatch @testAgainstLatestRelease -->
 ```bash
 cat <<EOF >>$DEMO_HOME/kustomization.yaml
 patchesJson6902:
@@ -116,7 +116,7 @@ EOF

 运行 `kustomize build $DEMO_HOME`, 在输出那里确认有 `/test` 这个路径.

-<!-- @confirmYamlPatch @test -->
+<!-- @confirmYamlPatch @testAgainstLatestRelease -->
 ```bash
 test 1 == \
  $(kustomize build $DEMO_HOME | grep "path: /test" | wc -l); \
--- a/travis/pre-commit.sh
+++ b/travis/pre-commit.sh
@@ -21,33 +21,64 @@ function runFunc {
  if [ $code -ne 0 ]; then
    result="FAILURE"
  fi
-  printf "============== end %s : %s code=%d\n\n\n" "$name" "$result" $code
+  printf "============== end %s : %s; exit code=%d\n\n\n" "$name" "$result" $code
 }

 function testGoLangCILint {
  golangci-lint run ./...
 }

-function testGoTest {
+function testGoTests {
  go test -v ./...
-}

-# These tests require the helm program, and at the moment
-# we're not asking travis to install helm.
-function testNoTravisGoTest {
-  go test -v sigs.k8s.io/kustomize/v3/pkg/target \
+  if [ -z ${TRAVIS+x} ]; then
+    echo " "
+    echo Not on travis, so running the notravis Go tests
+    echo " "
+    
+    # Requires helm.
+    # At the moment not asking travis to install it.
+    go test -v sigs.k8s.io/kustomize/v3/pkg/target \
      -run TestChartInflatorPlugin -tags=notravis
-  go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/chartinflator/... \
-    -run TestChartInflator -tags=notravis
-  mdrip --mode test --label helmtest README.md ./examples/chart.md
-  go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
+    go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/chartinflator/... \
+      -run TestChartInflator -tags=notravis
+
+    # Requires kubeeval.
+    # At the moment not asking travis to install it.
+    go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
       -run TestValidatorHappy -tags=notravis
-  go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
+    go test -v sigs.k8s.io/kustomize/v3/plugin/someteam.example.com/v1/validator/... \
       -run TestValidatorUnHappy -tags=notravis
+  fi
 }

-function testExamples {
-  mdrip --mode test --label test README.md ./examples
+function testExamplesAgainstLatestRelease {
+  /bin/rm -f $HOME/go/bin/kustomize
+  # Install latest release.
+  go get sigs.k8s.io/kustomize/v3/cmd/kustomize
+  PATH=$HOME/go/bin:$PATH \
+    mdrip --mode test --label testAgainstLatestRelease ./examples
+
+  if [ -z ${TRAVIS+x} ]; then
+    echo " "
+    echo Not on travis, so running the notravis example tests
+    echo " "
+
+    # Requires helm.  At the moment not asking travis to install it.
+    PATH=$HOME/go/bin:$PATH \
+      mdrip --mode test --label helmtest README.md ./examples/chart.md
+  fi
+}
+
+function testExamplesAgainstHead {
+  /bin/rm -f $HOME/go/bin/kustomize
+  # Install from head.
+  go install sigs.k8s.io/kustomize/v3/cmd/kustomize
+  # To test examples of unreleased features, add
+  # examples with code blocks annotated with some
+  # label _other than_ @testAgainstLatestRelease.
+  PATH=$HOME/go/bin:$PATH \
+    mdrip --mode test --label testAgainstLatestRelease ./examples
 }

 function generateCode {
@@ -100,15 +131,9 @@ echo "Working..."

 runFunc generateCode
 runFunc testGoLangCILint
-runFunc testGoTest
-
-if [ -z ${TRAVIS+x} ]; then
-  echo Not on travis, so running the notravis tests
-  runFunc testNoTravisGoTest
-fi
-
-PATH=$HOME/go/bin:$PATH
-runFunc testExamples
+runFunc testGoTests
+runFunc testExamplesAgainstLatestRelease
+runFunc testExamplesAgainstHead

 if [ $rc -eq 0 ]; then
  echo "SUCCESS!"