[TASK] GHA workflow to publish backend container image as a GHCR package

[andyatmiami]

Certification

• I certify I am an Epic Owner for Kubeflow Notebooks 2.0 and expected to create planning-related issues.

Description

As we move forward with the maturation of the Kubeflow Notebooks 2.0 application - we need to surface publicly available container images to allow consumers the ability to install Kubeflow Notebooks 2.0 on their cluster without needing to manually build the container images themselves.

This task is specifically related to the creation of a GHA workflow to handle publishing of the backend container image whose source code resides at workspaces/backend on the notebooks-v2 branch of the kubeflow/notebooks repository.

Important characteristics of the solution:

• on: triggers should be aligned/consistent with the testing workflows that exist in the codebase today
• image is to be published to the ghcr.io kubeflow/notebooks container registry
• image name should be workspaces-backend
• default tagging strategy should mimic that which was originally present in kubeflow/kubeflow
  • https://github.com/kubeflow/kubeflow/blob/master/components/example-notebook-servers/codeserver/Makefile#L15-L16
    • ⚠️ However, please note we do NOT want to leverage the latest tag in any of our automation
• when code is merged from a release branch - the tag should reflect the value of the releasing/version/VERSION file
• container image should be be produced any time any change is delivered to the workspaces/ directory
  • i.e. even if a workspaces/frontend change is merged from a PR - that should cause a workspaces-backend container image to be pushed

Acceptance Criteria

• When code is merged into the notebooks-v2 branch from a PR that contains changes in the workspaces/ directory - a container image for workspaces-backend with a sha-based tag should be published to ghcr.io
  • example: ghcr.io/kubeflow/notebooks/workspaces-backend:sha-3fa851ab3173942dbaa1a609468e7f9eadf5f4e4
• When publishing a container image for workspaces-backend, and uncommitted changes are detected on the branch - a suffix of -dirty should be appended to the tag
  • example: ghcr.io/kubeflow/notebooks/workspaces-backend:sha-3fa851ab3173942dbaa1a609468e7f9eadf5f4e4-dirty
• When publishing a container image from a release branch (v*-branch) a container image for workspaces-backend with a semantically versioned tag should be published to ghcr.io
  • example: ghcr.io/kubeflow/notebooks/workspaces-backend:v2.0.0
    • value of the tag should be read from releasing/version/VERSION

[andyatmiami]

/assign

[andyatmiami]

/close

implemented in #605