Update test-infra to include latest features of release.sh (knative#2625

)

* Update test-infra to include latest features of release.sh

Major changes:
* use flags instead of environment variables for setting GCR/GCS
* log configuration at the start of the process
* be more verbose when tagging/publishing

* Update deps to fix build tests

* Less diffs in md

hack/release.md

@@ -3,7 +3,8 @@
 The `release.sh` script automates the creation of Knative Serving releases,
 either nightly or versioned ones.
 
-By default, the script creates a nightly release but does not publish anywhere.
+By default, the script creates a nightly release but does not publish it
+anywhere.
 
 ## Common flags for cutting releases
 
@@ -16,12 +17,16 @@ release.
 - `--tag-release`, `--notag-release` Tag (or not) the generated images with
   either `vYYYYMMDD-<commit_short_hash>` (for nightly releases) or `vX.Y.Z` for
   versioned releases. _For versioned releases, a tag is always added._
+- `--release-gcs` Defines the GCS bucket where the manifests will be stored.
+  By default, this is `knative-nightly/serving`. This flag is ignored if the
+  release is not being published.
+- `--release-gcr` Defines the GCR where the images will be stored. By default,
+  this is `gcr.io/knative-nightly`. This flag is ignored if the release is not
+  being published.
 - `--publish`, `--nopublish` Whether the generated images should be published to
   a GCR, and the generated manifests written to a GCS bucket or not. If yes, the
-  destination GCR is defined by the environment variable `$SERVING_RELEASE_GCR`
-  (defaults to `gcr.io/knative-nightly`) and the destination GCS bucket is
-  defined by the environment variable `$SERVING_RELEASE_GCS` (defaults to
-  `knative-nightly/serving`). If no, the images will be pushed to the `ko.local`
+  `--release-gcs` and `--release-gcr` flags can be used to change the default
+  values of the GCR/GCS used. If no, the images will be pushed to the `ko.local`
   registry, and the manifests written to the local disk only (in the repository
   root directory).
 

hack/release.sh

@@ -16,15 +16,6 @@
 
 source $(dirname $0)/../vendor/github.com/knative/test-infra/scripts/release.sh
 
-# Set default GCS/GCR
-: ${SERVING_RELEASE_GCS:="knative-nightly/serving"}
-: ${SERVING_RELEASE_GCR:="gcr.io/knative-nightly"}
-readonly SERVING_RELEASE_GCS
-readonly SERVING_RELEASE_GCR
-
-# Set the repository
-export KO_DOCKER_REPO="${SERVING_RELEASE_GCR}"
-
 # Script entry point
 
 initialize $@
@@ -34,28 +25,23 @@ set -o pipefail
 
 run_validation_tests ./test/presubmit-tests.sh
 
+# Build the release
+
 banner "Building the release"
 
 # Build should not try to deploy anything, use a bogus value for cluster.
 export K8S_CLUSTER_OVERRIDE=CLUSTER_NOT_SET
 export K8S_USER_OVERRIDE=USER_NOT_SET
 export DOCKER_REPO_OVERRIDE=DOCKER_NOT_SET
 
-echo "- Destination GCR: ${KO_DOCKER_REPO}"
-if (( PUBLISH_RELEASE )); then
-  echo "- Destination GCS: ${SERVING_RELEASE_GCS}"
-fi
-
-# Build the release
-
 # Run `generate-yamls.sh`, which should be versioned with the
 # branch since the detail of building may change over time.
 readonly YAML_LIST="$(mktemp)"
 $(dirname $0)/generate-yamls.sh "${REPO_ROOT_DIR}" "${YAML_LIST}"
 readonly YAMLS_TO_PUBLISH=$(cat "${YAML_LIST}" | tr '\n' ' ')
 readonly RELEASE_YAML="$(head -n1 ${YAML_LIST})"
 
-tag_images_in_yaml "${RELEASE_YAML}" "${KO_DOCKER_REPO}" "${TAG}"
+tag_images_in_yaml "${RELEASE_YAML}"
 
 echo "New release built successfully"
 
@@ -68,8 +54,7 @@ fi
 # Publish the release
 # We publish our own istio.yaml, so users don't need to use helm
 for yaml in ${YAMLS_TO_PUBLISH}; do
-  echo "Publishing ${yaml}"
-  publish_yaml "${yaml}" "${SERVING_RELEASE_GCS}" "${TAG}"
+  publish_yaml "${yaml}"
 done
 
 branch_release "Knative Serving" "${YAMLS_TO_PUBLISH}"