prow icon indicating copy to clipboard operation
prow copied to clipboard

build images using cloudbuild

Open upodroid opened this issue 1 year ago • 7 comments

Part of https://github.com/kubernetes-sigs/prow/issues/113 Part of https://github.com/kubernetes/k8s.io/pull/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

upodroid avatar Apr 21 '24 13:04 upodroid

Deploy Preview for k8s-prow ready!

Name Link
Latest commit d3a7f94ea2647e21d83f8b47e60b3459092490ba
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...

QR Code

Use your smartphone camera to open QR code link.

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

netlify[bot] avatar Apr 21 '24 13:04 netlify[bot]

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

ameukam avatar Apr 22 '24 06:04 ameukam

#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

upodroid avatar Apr 22 '24 10:04 upodroid

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.

ameukam avatar Apr 22 '24 10:04 ameukam

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.

upodroid avatar Apr 22 '24 10:04 upodroid

/approve /lgtm /hold please remove hold as needed

dims avatar May 04 '24 20:05 dims

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.

BenTheElder avatar May 06 '24 17:05 BenTheElder

/cc @droslean @matthyx

I would like to get this merged soon, thanks

upodroid avatar May 14 '24 17:05 upodroid

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

matthyx avatar May 14 '24 19:05 matthyx

[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:

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

k8s-ci-robot avatar May 14 '24 19:05 k8s-ci-robot

/hold cancel

upodroid avatar May 15 '24 11:05 upodroid