[Test] Reduce Katib GitHub Action Runs

[andreyvelich]

Related: #2024.

I've made few changes to improve our Actions execution.

• Rename all e2e test files to make it easier to identify them.
• In this PR: gh-actions: Extend action to run Frontend Unit tests #1998, we disabled publish actions on Katib UI changes. I think, we should disable only e2e for the Katib UI changes. We want to give user an option to install all Katib Control Plane images with the particular GitHub commit. That is why we publish all Katib images on every PR.
• I removed postgres e2e from all test and created new e2e test: e2e-test-ui-random-search-postgres.yaml. In that test we check that Katib UI can be deployed on minikube + run random search with postgres DB.
• Move shellcheck and YAML lint to the 1 workflow. I think, in the future PRs we should combine all unit test/lint checks in the 1 workflow.
• Remove push execution from all unit/lint tests.
• Add cancel-in-progress flag to our e2e workflows.
• Use single job for Katib Charmed actions.

/assign @johnugeorge @tenzen-y @anencore94 @kimwnasptd @orfeas-k

[andreyvelich]

cancel-in-progress seems to be working for E2E: https://github.com/kubeflow/katib/actions/runs/3534409566
Thank you @terrytangyuan!

[andreyvelich]

@DomFleischmann @knkski @ca-scribner
Please can you take a look on Katib Charmed error, I didn't make any changes for the execution process:

+ juju bundle deploy --build --destructive-mode --serial
Building and deploying bundle from bundle.yaml
Building katib-controller
Skipping 'bases[0].build-on[0]': channel '20.04' does not match host '22.04'.
No suitable 'build-on' environment found in 'bases[0]' configuration.
No suitable 'build-on' environment found in any 'bases' configuration. (full execution logs in '/tmp/charmcraft-log-swxyqidp')
Error: Error running subcommand ``charmcraft pack -p ./katib-controller --destructive-mode``: `exit status: 1`
Error: Process completed with exit code 1.

[anencore94]

Looks much clear ! Thanks for your efforts.
Just one question about Remove push execution from all unit/lint tests.

If there is no master branch protection rule such as Require branches to be up to date before merging, I think we need to check such tests after the PR is merged too. WDYT ?

[terrytangyuan]

Great!

[johnugeorge]

@DomFleischmann @knkski @ca-scribner Please can you take a look on Katib Charmed error, I didn't make any changes for the execution process:

+ juju bundle deploy --build --destructive-mode --serial
Building and deploying bundle from bundle.yaml
Building katib-controller
Skipping 'bases[0].build-on[0]': channel '20.04' does not match host '22.04'.
No suitable 'build-on' environment found in 'bases[0]' configuration.
No suitable 'build-on' environment found in any 'bases' configuration. (full execution logs in '/tmp/charmcraft-log-swxyqidp')
Error: Error running subcommand ``charmcraft pack -p ./katib-controller --destructive-mode``: `exit status: 1`
Error: Process completed with exit code 1.

This error is seen in other PRs as well. Can you help fix it at the earliest? @DomFleischmann @knkski @ca-scribner

[johnugeorge]

I am not sure if we need to publish all images during every commit. We will have to reconsider as this will slow down the whole development process. The user can build images any time using https://github.com/kubeflow/katib/blob/master/scripts/v1beta1/build.sh

[kimwnasptd]

@andreyvelich I'm not fully in sync with why we need to use concurrency. Could you provide some more context?

[anencore94]

It is useful when the developer push multiple commits on an open PR in short period.
#2024 (comment)

To cancel previous-running workflows and run with new source codes.

[andreyvelich]

Yes, @anencore94 is right, when the newer commit has been pushed, previous workflows are canceled.
@kimwnasptd You can check an example here: https://github.com/kubeflow/katib/actions/runs/3534409566

[DomFleischmann]

This error is seen in other PRs as well. Can you help fix it at the earliest? @DomFleischmann @knkski @ca-scribner

This seems to be because the we are using ubuntu-latest here which lately was updated to 22.04. By pinning this to 20.04 again things should work.

[andreyvelich]

I am not sure if we need to publish all images during every commit. We will have to reconsider as this will slow down the whole development process. The user can build images any time using https://github.com/kubeflow/katib/blob/master/scripts/v1beta1/build.sh

@johnugeorge I don't think it will slow down the UI development. I disabled the most time consuming building suggestion images on pull requests:

katib/.github/workflows/publish-algorithm-images.yaml

Lines 5 to 7 in 01f4bcd

	pull_request:
	paths-ignore:
	- "pkg/new-ui/v1beta1/frontend/**"

Do you have any concerns to have these actions when PR is merged ?

I think, we have users who want to get the latest Katib features, and they can easily bump all of their images to the particular commit. If we don't push images of every commit, users have to check what commit they should take for each image.
WDYT @johnugeorge @gaocegege @tenzen-y @kimwnasptd ?

[andreyvelich]

The Charmed seems to be working now: https://github.com/kubeflow/katib/actions/runs/3564777436/jobs/5989685476
@DomFleischmann @johnugeorge @kimwnasptd Please take a look at the changes.

[johnugeorge]

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich, anencore94, johnugeorge, terrytangyuan

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 [andreyvelich,johnugeorge]

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

[tenzen-y]

@andreyvelich Thanks for this improvement!