Point release documentation to knative/test-infra (#281)

hack/release.md

@@ -1,71 +0,0 @@
-# Creating a new Knative Client release
-
-The `release.sh` script automates the creation of Knative Client releases, either
-nightly or versioned ones.
-
-By default, the script creates a nightly release but does not publish it
-anywhere.
-
-## Common flags for cutting releases
-
-The following flags affect the behavior of the script, no matter the type of the
-release.
-
-- `--skip-tests` Do not run tests before building the release. Otherwise, build,
-  unit and end-to-end tests are run and they all must pass for the release to be
-  built.
-- `--tag-release`, `--notag-release` Tag (or not) the generated binaries 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 binaries will be stored. By
-  default, this is `knative-nightly/client`. This flag is ignored if the release
-  is not being published.
-- `--publish`, `--nopublish` Whether the generated binaries should be published
-  to the GCS bucket or not. If yes, the `--release-gcs` flag can be used to change
-  the default value of the GCS used. If no, the binaries will be written to the
-  local disk only (in the repository root directory).
-
-## Creating nightly releases
-
-Nightly releases are built against the current git tree. The behavior of the
-script is defined by the common flags. You must have write access to the GCS
-bucket the release will be pushed to, unless `--nopublish` is used.
-
-Examples:
-
-```bash
-# Create and publish a nightly, tagged release.
-./hack/release.sh --publish --tag-release
-
-# Create release, but don't test, publish or tag it.
-./hack/release.sh --skip-tests --nopublish --notag-release
-```
-
-## Creating versioned releases
-
-_Note: only Knative admins can create versioned releases._
-
-To specify a versioned release to be cut, you must use the `--version` flag.
-Versioned releases are usually built against a branch in the Knative Client
-repository, specified by the `--branch` flag.
-
-- `--version` Defines the version of the release, and must be in the form
-  `X.Y.Z`, where X, Y and Z are numbers.
-- `--branch` Defines the branch in Knative Client repository from which the
-  release will be built. If not passed, the `master` branch at HEAD will be
-  used. This branch must be created before the script is executed, and must be
-  in the form `release-X.Y`, where X and Y must match the numbers used in the
-  version passed in the `--version` flag. This flag has no effect unless
-  `--version` is also passed.
-- `--release-notes` Points to a markdown file containing a description of the
-  release. This is optional but highly recommended. It has no effect unless
-  `--version` is also passed.
-
-If this is the first time you're cutting a versioned release, you'll be prompted
-for your GitHub username, password, and possibly 2-factor authentication
-challenge before the release is published.
-
-The release will be published in the _Releases_ page of the Knative Client
-repository, with the title _Knative Client release vX.Y.Z_ and the given release
-notes. It will also be tagged _vX.Y.Z_ (both on GitHub and as a git annotated
-tag).

hack/release.sh

@@ -14,6 +14,9 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
+# Documentation about this script and how to use it can be found
+# at https://github.com/knative/test-infra/tree/master/ci
+
 source $(dirname $0)/../vendor/github.com/knative/test-infra/scripts/release.sh
 source $(dirname $0)/build-flags.sh