Add gcbmgr (Container Builder Manager) for creating, viewing and mana…

…ging jobs.

--user-at-domain has been eliminated and the entire workflow is now based upon
the active GCP user at the time of the start of the process.  If that is not
set, cannot be set or invalid, do not continue. Replaced with GCP_USER.

Added Dockerfile for building k8s-cloud-builder container image.

README-gcb.md

@@ -0,0 +1,53 @@
+Table of Contents
+=================
+* [Intro](#intro)
+* [Typical Workflows](#typical-workflows)
+
+# Container Builder Staging and Release
+
+## Intro
+
+The Kubernetes release process can now be staged and released on both the GCP
+Container Builder (GCB) or on the desktop with the necessary permissions.
+
+## Typical Workflows
+
+The typical workflow is very simple and works similar to `anago` in both mock
+and `--nomock` variants with a clear division between the two.  Stage and
+release using either `--nomock` or in the default (mock) mode.
+
+The hybrid model is also supported
+* Stage on GCB
+* Release on desktop
+
+```
+# On GCB, stage a (mock) master branch build from head
+$ gcbmgr stage master --build-at-head
+
+# On GCB, stage a (mock) release-1.9 branch build using test signal
+$ gcbmgr stage release-1.9
+
+# On GCB, view last 5 jobs
+$ gcbmgr
+-OR-
+$ gcbmgr list
+
+# View completed staged builds
+$ gcbmgr staged
+
+# Release (from GCB)
+$ gcbmgr release master --buildversion=<a staged master build version>
+
+# Release (from GCB)
+$ gcbmgr release release-1.9 --buildversion=<a staged release-1.9 build version>
+
+# And of course the man page has all the most detailed and up to date info:
+$ gcbmgr -man
+```
+
+Guidance from `gcbmgr staged` instructs you how to release a staged build on
+GCB or the desktop.
+
+NOTE: Releases from GCB are currently unable to send email, so the update
+      occurs in the form of a new release tracking issue on the
+      kubernetes/sig-release repo (k8s-release-robot/sig-release for mock runs).

README.md

@@ -70,9 +70,17 @@ on a branch.  Without the [--official] flag, a beta would be created.
 
 There are two workflows you can choose from:
 1. Run through a complete release end to end
-2. Create any number of staged (--stage) releases and release from there
+2. Create staged (--stage) releases and release from there
 
-First try a staged alpha release:
+*NOTE:* Again, the tooling works by default in *mock mode* and runs in *"full
+production"* mode using `--nomock`.
+
+*IMPORTANT:* Staging and release workflows operate exclusively in either mock
+or `--nomock` modes.  If you stage something in mock mode, it is not available
+in `--nomock` mode.  Be sure to both stage and release with or without
+`--nomock`.
+
+First try a (mock) staged alpha release:
 ```
 $ anago master --stage
 ```
@@ -111,14 +119,14 @@ $ anago release-9.9.9
 
 ## Typical Workflows
 
-Stage an official (patch) release on your local disk:
+Stage a (mock) official patch release on your local disk:
 ```
 # add --build-at-head to force a build, otherwise rely on find_green_build
 # in-line to find a build candidate
 $ anago release-1.8 --stage
 ```
 
-Release previously staged official (patch) release from your local disk:
+Release previously (mock) staged official patch release from your local disk:
 ```
 # $buildversion will come from the output at the end of the above --stage run
 # as will this command-line in its entirety