Workflow for building and pushing the TF serving image. #196
Conversation
|
Please reference #50 in the PR description. Which version of TF does this end up building a Docker image for? |
There was a problem hiding this comment.
Here's where I think we should go with this:
We should create a push to build pipeline, so everytime push to GitHub we end up building a Docker image from the source at that revision.
We can do this by having prow trigger the workflow.
We should tag the images to be something like
:1.0-<job_kind>-<pr #> - -
All of which are prow environment variables:
https://github.com/kubernetes/test-infra/tree/master/prow
| commit: "master", | ||
| name: "new4", | ||
| namespace: "kubeflow-test-infra", | ||
| prow_env: "REPO_OWNER=google,REPO_NAME=kubeflow,PULL_BASE_SHA=master", |
There was a problem hiding this comment.
the REPO_OWNER should be kubeflow.
| @@ -0,0 +1,31 @@ | |||
| # This pod is useful for starting a shell that you can use to interactively debug our tests | |||
| local artifactsDir = outputDir + "/artifacts"; | ||
| local srcDir = testDir + "/src"; | ||
| // local testing_image = "gcr.io/mlkube-testing/kubeflow-testing"; | ||
| local testing_image = "gcr.io/kai-test2/kubeflow-testing:1.0"; |
There was a problem hiding this comment.
Why is this point at kai-cloud?
If you need to override these values make the parameters and just override them per environment.
There was a problem hiding this comment.
I made some change to the Dockerfile (install docker).
Made it a param now.
|
Please update the PR description. Explain the motivation for this PR and why we are using Argo. |
|
Thanks, PTAL |
|
Lets change the directory to |
| local serving_image = params.serving_image; | ||
| local testing_image = params.testing_image; | ||
|
|
||
| // TODO(jlewi): Can we make name default so some random unique value? |
| @@ -0,0 +1,3 @@ | |||
| # Building and testing the TF serving image. | |||
|
|
|||
| work in progress. | |||
There was a problem hiding this comment.
The README should explain how I can trigger this workflow to build a TF Serving image. The README should explain the following
1. How to set which version of the Kubeflow source repository is used
2. How to set the GCR registry where the image is published to
3. Which version of TF serving is used.
|
PTAL |
| ## Build and Push | ||
| Set the gcr registry to be published to by `ks set param workflows serving_image gcr.io/xxx/xxx:xx`. | ||
|
|
||
| The TF serving image that the workflow is currently using is TF1.4 CPU, located at `components/k8s-model-server/docker`. |
There was a problem hiding this comment.
The text seems wrong. I assume you mean "TF version" not TF serving image?
|
|
||
| ## Checkout | ||
| The version of kubeflow is determined by the parameters such as `PULL_NUMBER` or `PULL_BASE_SHA`. | ||
| See [checkout.sh](https://github.com/kubeflow/testing/blob/master/images/checkout.sh) for more detail. |
There was a problem hiding this comment.
Add a link to this list here:
https://github.com/kubernetes/test-infra/tree/master/prow#job-environment-variables
|
done |
I have adde myself in the org.yaml. I have previously some small contributions and hope to continue do so :)
We want to have a workflow that automatically build and push the TF serving image from source, and run some test against it to verify it's working.
Argo is suitable for this kind of workflows, and it supports docker in docker.
In this PR, the workflows contains building+pushing part. (will add testing in followup PR).
It's using the Dockerfile in components/k8s-model-server/docker, which is a TF1.4 CPU image.
Related #50