gh-actions: Extend action to run Frontend Unit tests

[orfeas-k]

This is a follow up PR to this #1977. Here, we extend the GH action Frontend Test to include a job that runs KWA frontend unit tests as well. This also is needed before this PR #1991 (comment) is merged to ensure that nothing breaks.

[tenzen-y]

@orfeas-k Thanks for creating this!
I left a few comments.

/assign @kimwnasptd

[coveralls]

Coverage decreased (-0.1%) to 73.419% when pulling d358963 on arrikto:feature-orfeas-k-frontend-unit-tests-gh-action into b1ed847 on kubeflow:master.

[orfeas-k]

While working on this PR, I noticed that all jobs were queued and ran and thus, had to wait for a long time in order to verify if something breaks. After some discussion with @kimwnasptd , we thought it would be preferable if we could eliminate and run the jobs that are specific to each PR's changes. For that, we could utilise https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-excluding-paths and exclude the frontend path in jobs that are not related to it.

WDYT? Which workflows do you think we should run when there's a change in the frontend? cc @johnugeorge @andreyvelich @tenzen-y

[johnugeorge]

I think, for UI related changes, we need to run only https://github.com/kubeflow/katib/blob/master/.github/workflows/katib-ui-e2e-test.yaml and can skip all e2e tests.

@tenzen-y Any comments?

[kimwnasptd]

@johnugeorge @tenzen-y in this PR we also changed the .github/workflows/test-node.yaml for running the unit tests, and would extend it in the future to also run the integration tests.

Should we include this action as well for running unit/integration tests or should we migrate everything for the UI into the action you mentioned above?
https://github.com/kubeflow/katib/blob/master/.github/workflows/katib-ui-e2e-test.yaml

[johnugeorge]

@kimwnasptd If the integration tests requires images to be built, it is best to be added in https://github.com/kubeflow/katib/blob/master/.github/workflows/katib-ui-e2e-test.yaml as the workflow already does it for you.
If not, you can keep all tests in github/workflows/test-node.yaml itself.

[tenzen-y]

I think, for UI related changes, we need to run only https://github.com/kubeflow/katib/blob/master/.github/workflows/katib-ui-e2e-test.yaml and can skip all e2e tests.

@tenzen-y Any comments?

@johnugeorge
Thanks for reminding me.

@kimwnasptd If the integration tests requires images to be built, it is best to be added in https://github.com/kubeflow/katib/blob/master/.github/workflows/katib-ui-e2e-test.yaml as the workflow already does it for you.
If not, you can keep all tests in github/workflows/test-node.yaml itself.

I agree with you.

@kimwnasptd
I also think that we can skip any other e2e tests except katib-ui-e2e-test for only UI code changes.

[orfeas-k]

@kimwnasptd @johnugeorge @tenzen-y I pushed another commit in order to exclude workflows from running when there are changes only in the frontend, just as we discussed here. I'm also removing the WIP - also from this PR.

[kimwnasptd]

Thanks @orfeas-k. LGTM from my side. I think we'll only need to re-run one action.

/lgtm

[johnugeorge]

/assign @tenzen-y

[tenzen-y]

@orfeas-k Thanks for updating!
/lgtm

/assign @kubeflow/wg-automl-leads

[johnugeorge]

/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: johnugeorge, orfeas-k

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:

• OWNERS [johnugeorge]

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