Evaluate the new crud-web-apps workflow files for KF1.7

[mathis-marcotte]

Evaluate the new github workflows from KF1.7 for jupyter apis to see if we could and should bring them in to jupyter-apis.

.github/workflows
See comments for more details.

• common_frontend_tests.yaml : ✔️
• jwa_backend_unittests.yaml (This one is for their python backend, so it can't really translate 1 for 1 with our golang backend. But maybe we can alter this to work for our golang.) : ❌
• jwa_docker_publish.yaml (similar to our publish.yaml) ✔️
• jwa_frontend_tests.yaml (like our frontend_tests.yml) ✔️
• jwa_intergration_test.yaml ✔️
• vwa_docker_publish.yaml ❌
• vwa_frontend_tests.yaml ❌
• vwa_intergration_test.yaml ❌

[mathis-marcotte]

common_frontend_tests.yaml

Its on pull requests including the kubeflow-common-lib.
First runs ng lint and prettier.
Then runs ng test.

I don't see a reason not to use this workflow unless we want to avoid linting, but it makes sense to do it.

[mathis-marcotte]

jwa_backend_unittests.yaml

On PRs including the jupyter backend.
First installs kind. It's a tool for running local Kubernetes clusters using Docker container “nodes”, and was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
Then sets up the env by creating a kind cluster and installing the python deps to then run python -m unittest discover --pattern "*_test.py"
As far as I can tell, the python backend only has one file matching the pattern. and it looks to be mainly about testing functions related to volumes.
It could be good eventually for our golang backend to have unit tests. But we currently don't have any. And with the upstream backend only having a small amount of unit tests, I would say that we can hold off on importing something like this workflow for our code.

[mathis-marcotte]

jwa_docker_publish.yaml

On pushes to master or v*-branch for changes in crud-web-apps common or jupyter.
Just builds and pushes the docker image for jupyter crud-web-apps.
We already have a workflow that does something like this with our publish.yml workflow. We could just verify that our workflow is still up to date based on this one.

[mathis-marcotte]

jwa_frontend_tests.yaml

On PRs to jupyter frontend.
First checks the formatting and linting of the frontend.
Then runs ng test and then cypress run.
This just runs all the frontend tests. We already have some steps from this in our frontend_tests.yml workflow to just run the cypress. It would just be a matter of updating our workflow to also run ng test

[mathis-marcotte]

jwa_intergration_test.yaml

On PRs including crud-web-apps common or jupyter, as well as to branches master or "v*-branch".
Tests to make sure the image can run on a kube pod.
We could definitely try to intergrate this one in our repo.

[mathis-marcotte]

vwa_docker_publish.yaml

Looks like the exact same workflow as jwa_docker_publish.yaml, but pointing to the volumes crud-web-apps. Since we merge the jupyter and volumes apps together, we don't need to import this workflow.

[mathis-marcotte]

vwa_frontend_tests.yaml

Looks to be almost exactly like jwa_frontend_tests.yaml but for volumes. The only main difference is that in the vwa workflow, they run the cypress tests in two seperate steps(one on chrome and one on firefox), while in jwa the workflow runs a single step that tests for both browsers. Essentially results to the same thing. Since we merge the jupyter and volumes apps together, we don't need to import this workflow.

[mathis-marcotte]

vwa_intergration_test.yaml

Looks like the exact same workflow as jwa_intergration_test.yaml, but pointing to the volumes crud-web-apps. Since we merge the jupyter and volumes apps together, we don't need to import this workflow.