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)
This file is used by the push-to-staging postsubmit job that builds images and pushes them to a staging repo.
When it was originally added, my theory for why the job was failing [0] is that we were only uploading the ci/postsubmit/push-to-staging directory to GCS for use in cloudbuild, when in reality we need to push the entire kops repo so it can run `make kops-controller-push`.
A while back I had updated the job to use the repo root but hadnt created the cloudbuild.yaml file there yet, so instead we've been getting a cloudbuild.yaml not found error [1].
This moves the cloudbuild.yaml into the repo root so that the current job configuration will recognize it and hopefully be able to run `make kops-controller-push` in GCB.
[0] https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/kops-postsubmit-push-to-staging/1209130004504383489
[1] https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/kops-postsubmit-push-to-staging/1213230826582446081
This means we won't be able to work unless there's a bucket permission
(which actually will typically happen if the state store is in the
same GCS project).
This is the minimal workaround for cherry-picking.
Writing to a hostPath from a non-root container requires file
ownership changes, which is difficult to roll out today. See
discussion in #8454
We were primarily using the logfile for e2e diagnostics, so we're
going to look into collecting the information via other means instead.
We also haven't yet shipped this logfile in a released version (though
we have shipped it in beta releases)
Kubernetes Prow Robot