This avoids duplication of logic / different logic - and the logic in
the Makefile was indeed different, which was causing us to overwrite
the staging alpha images.
This is working towards "hands off" release builds, where we just tag
the release. When CI=1 and the git sha we are building _exactly_
matches a tag, we build that version. We enforce that version.go must
have previously been updated to match the tag.
We also refactor out the duplicated code into a shared script (tools/get_version.sh)
kube-apiserver doesn't expose the healthcheck via a dedicated
endpoint, instead relying on anonyomous-access being enabled. That
has previously forced us to enable the unauthenticated endpoint on
127.0.0.1:8080.
Instead we now run a small sidecar container, which
proxies /healthz and /readyz requests (only) adding appropriate
authentication using a client certificate.
This will also enable better load balancer checks in future, as these
have previously been hampered by the custom CA certificate.
Co-authored-by: John Gardiner Myers <jgmyers@proofpoint.com>
The image pushing postsubmit job [0] is one step closer to succeeding.
It currently fails because when the builder image uploads the kops directory to GCS for to be consumed by GCB, it excludes the .git directory [1].
This causes the job to fail because `make kops-controller-push` uses bazel which runs get_workspace_status.sh which aborts if the git commands fail.
The prow job doesnt contain much output but the GCB logs can be seen in GCS [2].
This PR removes the dependency on git commands.
I dont think any of the logic in the script will change because we already set VERSION [3] which is the only variable in get_workspace_status.sh that depends on git commands and is used to build and push the kops controller image.
[0] https://testgrid.k8s.io/sig-cluster-lifecycle-kops#kops-postsubmit-push-to-staging
[1] 18391d8986/images/builder/main.go (L87)
[2] gs://k8s-staging-kops-gcb/logs/log-a7dc3a24-97cd-42fe-bec3-971dc78a0e3a.txt
[3] b1276ac835/cloudbuild.yaml (L10)
So I figured out how to generate the outputs in the correct way so
that we don't need an artificial name; we must construct the outputs
field in the rule using a helper function.
We can move the gzip & sha steps from the makefile to bazel. This not
only simplifies the makefile, it should enable more parallelism and
better caching.
We can continue to support platforms that have either shasum or
sha1sum / sha256sum. but we can move that logic to a helper so that
our makefile is simpler, and also so that we can use the same helper
in bazel in future.
See https://github.com/bazelbuild/bazel/issues/6319
The default bazelrc location is changing. So that we don't break
during the transition, we set up an alias so that bazel versions that
load from the new location are redirected to the old location.
Also add a TODO to move to the new location once bazel 0.18 is
prevalent.
We bumped the version in the Makefile, but I did not understand that we
have to bump the version in the workplace status script. I added a note
in the Makefile, and bumped the version in the script.
Ole Markus With
justinsb
John Gardiner Myers
Peter Rifel
mikesplain
Erick Fejta
Justin Santa Barbara
chrislovecnm