build images using cloudbuild

[upodroid]

Part of #113
Part of kubernetes/k8s.io#6740

Right now, our postsubmit job runs in a pod which breaks our trusted cluster build policies.

I tested this build at https://console.cloud.google.com/cloud-build/builds;region=global/ce637e5c-b605-490f-b104-589b7dca23c6?project=k8s-infra-ii-sandbox

@BenTheElder @ameukam

[netlify]

✅ Deploy Preview for k8s-prow ready!

Name	Link
🔨 Latest commit	d3a7f94
🔍 Latest deploy log	https://app.netlify.com/sites/k8s-prow/deploys/66439a75ef1c2e0009b230e5
😎 Deploy Preview	https://deploy-preview-123--k8s-prow.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[upodroid]

an empty .gcloudignore allows GCB to upload the .git folder which is required by hack/prowimagebuilder to run git commands to fetch git status.

[ameukam]

To my understanding, #113 states that we should attempt to promote prow components to registry.k8s.io ?

[upodroid]

#113 requires Prow maintainers to start versioning prow and promote the release images to registry.k8s.io. In the meanwhile, we need to be able to publish and consume unversioned prow images from an AR registry called us-docker.pkg.dev/k8s-infra-prow/images

[ameukam]

The location of the prow components is not a hard requirement to bootstrap a cluster for prow and we specially don't need to co-locate a AR registry and a GKE cluster.
Also a regional AR would be more sustainable and cost-effective.

[upodroid]

Also a regional AR would be more sustainable and cost-effective.

Pricing is the same for both storage and bandwidth. https://cloud.google.com/artifact-registry/pricing#storage

prow and we specially don't need to co-locate a AR registry and a GKE cluster.

I'm doing this for convenience. Prow images are a special case and will need to be stored for more than 60 days(how long is TBD) and AR has a good security boundary, unlike GCR which interacts with GCS so a dedicated staging project makes no sense. The approach in k8s-prow where the cluster and images are in the project works for us.

[dims]

/approve
/lgtm
/hold please remove hold as needed

[BenTheElder]

Pricing is the same for both storage and bandwidth. https://cloud.google.com/artifact-registry/pricing#storage

currently

Prow images are a special case and will need to be stored for more than 60 days

They shouldn't be. Which other projects would we special-case?

The only special case I know currently is registry.k8s.io because we would have a circular dependency problem.

[upodroid]

/cc @droslean @matthyx

I would like to get this merged soon, thanks

[matthyx]

/approve
/lgtm
Please remove the hold if @BenTheElder comment is addressed.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, matthyx, upodroid

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [matthyx]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[upodroid]

/hold cancel