disable edit add patch command tests temporarily

examples/configGeneration.md

@@ -28,7 +28,9 @@ 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 @testAgainstLatestRelease -->
+
 ```
 DEMO_HOME=$(mktemp -d)
 
@@ -55,7 +57,9 @@ EOF
 ```
 
 Establish the staging with a patch applied to the ConfigMap
+
 <!-- @establishStaging @testAgainstLatestRelease -->
+
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -92,8 +96,8 @@ configured with data from a configMap.
 
 The deployment refers to this map by name:
 
-
 <!-- @showDeployment @testAgainstLatestRelease -->
+
 ```
 grep -C 2 configMapKeyRef $BASE/deployment.yaml
 ```
@@ -106,8 +110,8 @@ changed, so such updates have no effect.
 The recommended way to change a deployment's
 configuration is to
 
- 1. create a new configMap with a new name,
- 1. patch the _deployment_, modifying the name value of
+1.  create a new configMap with a new name,
+1.  patch the _deployment_, modifying the name value of
     the appropriate `configMapKeyRef` field.
 
 This latter change initiates rolling update to the pods
@@ -120,6 +124,7 @@ collected](/../../issues/242).
 The _staging_ [variant] here has a configMap [patch]:
 
 <!-- @showMapPatch @testAgainstLatestRelease -->
+
 ```
 cat $OVERLAYS/staging/map.yaml
 ```
@@ -131,6 +136,7 @@ resource spec.
 The ConfigMap it modifies is declared from a configMapGenerator.
 
 <!-- @showMapBase @testAgainstLatestRelease -->
+
 ```
 grep -C 4 configMapGenerator $BASE/kustomization.yaml
 ```
@@ -144,6 +150,7 @@ kustomize modifies names of ConfigMaps declared from ConfigMapGenerator.  To see
 ultimately used in the cluster, just run kustomize:
 
 <!-- @grepStagingName @testAgainstLatestRelease -->
+
 ```
 kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
@@ -161,7 +168,8 @@ The suffix to the configMap name is generated from a
 hash of the maps content - in this case the name suffix
 is _5276h4th55_:
 
-<!-- @grepStagingHash -->
+<!-- @grepStagingHash @testAgainstLatestRelease -->
+
 ```
 kustomize build $OVERLAYS/staging | grep 5276h4th55
 ```
@@ -170,6 +178,7 @@ Now modify the map patch, to change the greeting
 the server will use:
 
 <!-- @changeMap @testAgainstLatestRelease -->
+
 ```
 sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
 ```
@@ -184,6 +193,7 @@ kustomize build $OVERLAYS/staging |\
 Run kustomize again to see the new configMap names:
 
 <!-- @grepStagingName @testAgainstLatestRelease -->
+
 ```
 kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
@@ -194,7 +204,8 @@ in three new names ending in _c2g8fcbf88_ - one in the
 configMap name itself, and two in the deployment that
 uses the map:
 
-<!-- @countHashes -->
+<!-- @countHashes @testAgainstLatestRelease -->
+
 ```
 test 3 == \
   $(kustomize build $OVERLAYS/staging | grep c2g8fcbf88 | wc -l); \

examples/springboot/README.md

@@ -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 @testAgainstLatestRelease -->
+<!-- @customizeConfigMap -->
 ```
 cat <<EOF >$DEMO_HOME/patch.yaml
 apiVersion: apps/v1
@@ -281,7 +281,7 @@ The output contains
 
 Add these patches to the kustomization:
 
-<!-- @addPatch @testAgainstLatestRelease -->
+<!-- @addPatch -->
 ```
 cd $DEMO_HOME
 kustomize edit add patch --path memorylimit_patch.yaml --name sbdemo --kind Deployment --group apps --version v1

examples/zh/configGeneration.md

@@ -5,6 +5,7 @@
 ## ConfigMap 的生成和滚动更新
 
 kustomize 提供了两种添加 ConfigMap 的方法：
+
 - 将 ConfigMap 声明为 [resource]
 - 通过 ConfigMapGenerator 声明 ConfigMap
 
@@ -30,7 +31,9 @@ kustomize 提供了两种添加 ConfigMap 的方法：
 ### 建立 base 和 staging
 
 使用 configMapGenerator 建立 base
+
 <!-- @establishBase @testAgainstLatestRelease -->
+
 ```
 DEMO_HOME=$(mktemp -d)
 
@@ -57,7 +60,9 @@ EOF
 ```
 
 通过应用 ConfigMap patch 的方式建立 staging
+
 <!-- @establishStaging @testAgainstLatestRelease -->
+
 ```
 OVERLAYS=$DEMO_HOME/overlays
 mkdir -p $OVERLAYS/staging
@@ -94,6 +99,7 @@ EOF
 deployment 按照名称引用此 ConfigMap ：
 
 <!-- @showDeployment @testAgainstLatestRelease -->
+
 ```
 grep -C 2 configMapKeyRef $BASE/deployment.yaml
 ```
@@ -102,8 +108,8 @@ grep -C 2 configMapKeyRef $BASE/deployment.yaml
 
 更改 Deployment 配置的推荐方法是：
 
- 1. 使用新名称创建一个新的 configMap
- 2. 为_deployment_ 添加 patch，修改相应 `configMapKeyRef` 字段的名称值。
+1.  使用新名称创建一个新的 configMap
+2.  为*deployment* 添加 patch，修改相应 `configMapKeyRef` 字段的名称值。
 
 后一种更改会启动对 deployment 中的 pod 的滚动更新。旧的 configMap 在不再被任何其他资源引用时最终会被[垃圾回收](/../../issues/242)。
 
@@ -112,6 +118,7 @@ grep -C 2 configMapKeyRef $BASE/deployment.yaml
 _staging_ 的 [variant] 包含一个 configMap 的 [patch]：
 
 <!-- @showMapPatch @testAgainstLatestRelease -->
+
 ```
 cat $OVERLAYS/staging/map.yaml
 ```
@@ -121,6 +128,7 @@ cat $OVERLAYS/staging/map.yaml
 在 ConfigMapGenerator 中声明 ConfigMap 的修改。
 
 <!-- @showMapBase @testAgainstLatestRelease -->
+
 ```
 grep -C 4 configMapGenerator $BASE/kustomization.yaml
 ```
@@ -130,6 +138,7 @@ grep -C 4 configMapGenerator $BASE/kustomization.yaml
 但是，文件中指定的名称值不是群集中使用的名称值。根据设计，kustomize 修改从 ConfigMapGenerator 声明的 ConfigMaps 的名称。要查看最终在群集中使用的名称，只需运行 kustomize：
 
 <!-- @grepStagingName @testAgainstLatestRelease -->
+
 ```
 kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
@@ -141,7 +150,8 @@ kustomize build $OVERLAYS/staging |\
 
 configMap 名称的后缀是由 map 内容的哈希生成的 - 在这种情况下，名称后缀是 _5276h4th55_ ：
 
-<!-- @grepStagingHash -->
+<!-- @grepStagingHash @testAgainstLatestRelease -->
+
 ```
 kustomize build $OVERLAYS/staging | grep 5276h4th55
 ```
@@ -149,6 +159,7 @@ kustomize build $OVERLAYS/staging | grep 5276h4th55
 现在修改 map patch ，更改该服务将使用的问候消息：
 
 <!-- @changeMap @testAgainstLatestRelease -->
+
 ```
 sed -i.bak 's/pineapple/kiwi/' $OVERLAYS/staging/map.yaml
 ```
@@ -163,6 +174,7 @@ kustomize build $OVERLAYS/staging |\
 再次运行 kustomize 查看新的 configMap 名称：
 
 <!-- @grepStagingName @testAgainstLatestRelease -->
+
 ```
 kustomize build $OVERLAYS/staging |\
     grep -B 8 -A 1 staging-the-map
@@ -170,7 +182,8 @@ kustomize build $OVERLAYS/staging |\
 
 确认 configMap 内容的更改将会生成以 _c2g8fcbf88_ 结尾的三个新名称 - 一个在 configMap 的名称中，另两个在使用 ConfigMap 的 deployment 中：
 
-<!-- @countHashes -->
+<!-- @countHashes @testAgainstLatestRelease -->
+
 ```
 test 3 == \
   $(kustomize build $OVERLAYS/staging | grep c2g8fcbf88 | wc -l); \

examples/zh/springboot.md

@@ -89,7 +89,7 @@ cat kustomization.yaml
 1. 通过 patch 添加一个环境变量
 2. 将文件添加到 ConfigMap 中
 
-<!-- @customizeConfigMap @testAgainstLatestRelease -->
+<!-- @customizeConfigMap -->
 ```
 cat <<EOF >$DEMO_HOME/patch.yaml
 apiVersion: apps/v1
@@ -257,7 +257,7 @@ cat $DEMO_HOME/healthcheck_patch.yaml
 
 将这些 patch 添加到 `kustomization.yaml` 中：
 
-<!-- @addPatch @testAgainstLatestRelease -->
+<!-- @addPatch -->
 ```
 cd $DEMO_HOME
 kustomize edit add patch --path memorylimit_patch.yaml --name sbdemo --kind Deployment --group apps --version v1