setup kfctl nightly builds

[swiftdiaries]

trafficstars

It would be great if we could setup nightly builds for kfctl. It would go well along with the E2E tests and help in development.

/cc @kkasravi @jlewi @yanniszark

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label improvement/enhancement to this issue, with a confidence of 0.97. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[swiftdiaries]

/assign @swiftdiaries

[jlewi]

@swiftdiaries What are you thinking in terms of how nightly builds are published?

[jlewi]

@swiftdiaries We could piggy back on our existing E2E tests to automatically publish the binary somewhere. It might be easiest to start with GCS just because our CI system already has access to GCS; accessing GitHub release pages is a bit more work but doable.

For GitHub I think we'd want to create a GitHub APP and use that to authenticate to our repos.

It might also make sense to try to use TektonCD/pipeline as that would allow us to break down our workflows into reusable tasks so we could have

• 1 Task to build kfctl
• 1 Task to push to GCS
• 1 Task to push to GitHub
• 1 Task to deploy Kubeflow
• N tasks testing that Kubeflow is valid

We currently have a makefile which builds kfctl and pushes it to GitHub using hub-cli. https://github.com/kubeflow/kubeflow/blob/8da1e4709dfb53867cce9156ccd52945bd82af21/bootstrap/Makefile#L101

A think a good step might just be creating a 1 step Tekton pipeline to build kfctl.

[swiftdiaries]

@jlewi Are we looking to move from Argo to TektonCD for E2E tests?

[swiftdiaries]

+1 for pushing to GCS I'll get to the GitHub app in a subsequent PR, the initial one would just be a piggyback on the existing E2E workflow to build and push the kfctl binary to GCS. Although, for GCS should we create a separate bucket that can be accessed by devs or publish the nightly builds on GitHub?

[jlewi]

@swiftdiaries I think TektonCD is worth investigating but I wouldn't block any critical work on that.

Although, for GCS should we create a separate bucket that can be accessed by devs or publish the nightly builds on GitHub?

I would start with GCS just because its simpler. We can create a public bucket if necessary.

[jlewi]

@swiftdiaries Any update on this?

[swiftdiaries]

I've pushed a PR that takes builds off of the E2E test to create a bucket and push the binary. https://github.com/kubeflow/kubeflow/pull/3949 PTAL

[swiftdiaries]

I've added you as a reviewer on that PR

[jlewi]

@swiftdiaries any update on this?

[swiftdiaries]

I should move this into the kubeflow/kfct repo, I'll create another PR and close this one out

[jlewi]

@swiftdiaries I've moved the issue into the kubeflow/kfctl repo. Could you provide an update the current status? Do we have a PR? If so what work remains after that PR? What's blocking that PR if anything?

[swiftdiaries]

Sorry for the delay. Opened to PR to close this issue. I'll work through the PR and have it done ASAP

[swiftdiaries]

After this PR, we need a nightly periodic prow job defined for this repo so that we have nightly builds associated with that run

[jlewi]

@swiftdiaries any update on this?

[swiftdiaries]

I had a small question on this, have we moved the ProwJobs to oss-test-infra? Or would it be ok if we push changes to the ProwJobs to k8s/test-infra?

[jlewi]

@swiftdiaries we haven't moved our prow jobs yet so if you need to update jobs it will have to be in k8s/test-infra.

What changes need to be made to the prow jobs?

What is the remaining work to close this out?