Keep mandatory presubmit ci working after 1st of august

[chrischdi]

Hey folks,

the presubmit prowjob pull-ova-all is backed by infrastructure which is not owned by the community.
Starting by the 1st of August this job will not work anymore. (see this mail for more information)

We are working on it but do not yet have any estimate yet when we will have community owned infrastructure to run this job after 1st of August (also see this mail).

This prowjob currently is currently used as a signal to merge PRs and is mandatory to be green for merging, when the following paths have changes in a PR:

• images/capi/(Makefile|ansible\.cfg)
• images/capi/ansible/.*
• images/capi/scripts/ci-ova\.sh
• images/capi/packer/(config|goss|ova)/.*
• images/capi/hack/ensure-(ansible|packer|goss).*

Before hitting 1st of august we propably should:

• either make the pull-ova-all prowjob optional or remove it (as long as there is no new backing infrastructure yet available)
• maybe make pr-pull-image-builder-gcp-all or pr-azure-vhds not optional anymore to cover most of image-builder on every PR.
  • sidenote: pr-pull-image-builder-gcp-all is currently failing

[chrischdi]

Adding all currently listed maintainers for awareness :-) :

@AverageMarcus, @jsturtevant, @kkeshavamurthy, @mboersma, @drew-viles

cc @fabriziopandini @sbueringer

[mboersma]

Thanks for the heads up @chrischdi. I'm working on the changes for the pull-azure-vhds and pull-azure-sigs to migrate them to community infra and should be able to land that before August 1, so we will at least have some test signal against basic regressions.

It would be great if we could rehabilitate pr-pull-image-builder-gcp-all as well. I can take a look after I finish this work, but if anyone wants to volunteer before that, that would be excellent.

[drew-viles]

I'll be honest, I've not touched anything prow yet so wouldn't know right now where to start. Would love to see how it's done though if I can shadow through the process as PRs are raised etc?

For example I can see how I'd disable it by removing the run_if_changed section but I'm not clear on how it'd be made optional. As for the gcp one, I've not a clue right now!

Time to level myself up a bit around this section 😉

[chrischdi]

I'll be honest, I've not touched anything prow yet so wouldn't know right now where to start. Would love to see how it's done though if I can shadow through the process as PRs are raised etc?

For example I can see how I'd disable it by removing the run_if_changed section but I'm not clear on how it'd be made optional. As for the gcp one, I've not a clue right now!

Time to level myself up a bit around this section 😉

Making it optional is only about adding optional: true to the pull-ova-all job in this file:

https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes-sigs/image-builder/image-builder-ova-presubmits.yaml#L8

Prior art:

https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes-sigs/image-builder/image-builder-presubmits.yaml#L51

Happy to give guidance :-)

[mboersma]

WRT to the broken pull-image-builder-gcp-all job, see #1516.

[mboersma]

The two Azure prow jobs are now moved over to community infra, so that's everything except pull-ova-all.

@chrischdi please let us know if we can help with anything, or if we should go ahead and make pull-ova-all optional. I can take a look at fixing pull-image-builder-gcp-all next week.

[sbueringer]

@mboersma Please make pull-ova-all optional. We don't have community-owned infrastructure for vSphere yet, and we won't get it until 1st August

[mboersma]

Please make pull-ova-all optional

See kubernetes/test-infra#33052

[drew-viles]

Thanks for sorting this @mboersma .
Sorry I've not had chance to jump on this. It's been a mad week at home so just not had chance to log in and do much.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mboersma]

/remove-lifecycle stale

@chrischdi any progress on this?

[chrischdi]

Yes and no :-)

Progressing slowly, the target is still the same. I think this still takes 2-3+ months.