Add Workflow to Publish Katib Images

[andreyvelich]

After this PR, images will be automatically published to our Docker Hub after every commit to the master branch.
So we don't need to manually run make push-latest after each PR.
We still need to update repository settings with Docker Hub token.

GitHub Actions has limitation of 20 concurrent jobs: https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits in Free plan, that is why I split the workflows to: Core, Algorithms, and Trials.

Please take a look at this workflow.
/assign @gaocegege @johnugeorge @tenzen-y

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich

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]

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

[coveralls]

Coverage increased (+0.4%) to 74.138% when pulling bc60821 on andreyvelich:automate-image-publishing into 46207a3 on kubeflow:master.

[anencore94]

GitHub Actions has limitation of 20 concurrent jobs: https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits in Free plan, that is why I split the workflows to: Core, Algorithms, and Trials.

I think my suggestion method is somewhat bothersome stuff, but we could save limitation if we split each image's trigger point to only dependent PATH changed.

For example:

# for suggestion-hyperopt image,
on:
  push(or pull_request):
    paths:
      - "cmd/suggestions/hyperopt"
      - "pkg/apis/manager"
      - "pkg/suggestion/v1beta1/hyperopt"

# for enas-cnn-cifar10 image,
on:
  push(or pull_request):
    paths:
      - "examples/v1beta1/trial-images/enas-cnn-cifar10"

[tenzen-y]

This feature is very useful!
I left some comments.

[andreyvelich]

I think my suggestion method is somewhat bothersome stuff, but we could save limitation if we split each image's trigger point to only dependent PATH changed.

@anencore94 I think currently we give our users experience when they can use images with specific commit for all Katib components.
For example: v1beta1-0e17302, Katib Controller image, MXNet Mnist.

I think that approach simplify Katib usage to understand which changes our users try to deploy.
WDYT @anencore94 ?

[tenzen-y]

Thank you for the updating! @andreyvelich
/lgtm

[tenzen-y]

/hold

[anencore94]

@anencore94 I think currently we give our users experience when they can use images with specific commit for all Katib components.
For example: v1beta1-0e17302, Katib Controller image, MXNet Mnist.
I think that approach simplify Katib usage to understand which changes our users try to deploy.
WDYT @anencore94 ?

Yeah, This could make users feel much easier to try on. Thanks :)

[andreyvelich]

@james-jwu @zijianjoy @Bobgy Please take a look at this PR.
We have to update Katib repository settings with our Docker Hub token.

[andreyvelich]

We updated the token with @zijianjoy, let's try to merge this PR.
/hold cancel