feat: Migrate pvcviewer controller publish action

[noalimoy]

Summary

This PR migrates the GitHub Actions workflow responsible for building and publishing the PVCViewer Controller Docker image from the kubeflow/kubeflow repository to the kubeflow/notebooks repository.

Related: #619

Verification

Successfully built and published a test image:
GitHub Actions run

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign thesuperzapper for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

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

[andyatmiami]

/hold

I want to make sure:

• we finalize the decision on container registry
• we appropriately "seed" a package to appropriate container registry so desired permissions are in place

[andyatmiami]

/ok-to-test

[andyatmiami]

@noalimoy

Thanks for these changes.. I can confirm you appropriately copied the existing workflow from kubeflow/kubeflow and made the necessary edits.

HOWEVER - I'm VERY perplexed on how the original workflow was EVER working - as we clearly are attempting to build multi-arch images - but I don't see a Setup QEMU step like other workflows have ?!

Can you:

• explicitly add that step similar to how other _publish workflows have it defined
• explain to me how the heck this is working without that step???

🙇

[noalimoy]

@noalimoy

Thanks for these changes.. I can confirm you appropriately copied the existing workflow from kubeflow/kubeflow and made the necessary edits.

HOWEVER - I'm VERY perplexed on how the original workflow was EVER working - as we clearly are attempting to build multi-arch images - but I don't see a Setup QEMU step like other workflows have ?!

Can you:

• explicitly add that step similar to how other _publish workflows have it defined
• explain to me how the heck this is working without that step???

🙇

Ok, the reason the original and current workflow works without a Setup QEMU step is that our Go binary is statically built (CGO_ENABLED=0), which has important implications:

• The binary built for each architecture does not require execution during the build.
• Buildx can therefore generate layers and a manifest for each architecture without any emulation, using just the binary that was already built
  1. ARCH=linux/amd64 make docker-build-multi-arch
  2. ARCH=linux/ppc64le make docker-build-multi-arch
  3. ARCH=linux/arm64/v8 make docker-build-multi-arch
• If there were RUN commands during the build that depended on executing a binary - we would need QEMU to run that code

I agree it might be worth adding the Setup QEMU step for consistency and clarity..

[andyatmiami]

/lgtm

Thanks @noalimoy - good to finally be at a place to get this merged. appreciate your work!

Verified on fork:

• https://github.com/andyatmiami/kubeflow-notebooks/actions/runs/18956588486/job/54134806284
  • note: small commit to point to my repo
    • andyatmiami@aec02cb

Image available:

• https://github.com/andyatmiami/kubeflow-notebooks/pkgs/container/kubeflow-notebooks%2Fpvcviewer-controller

[andyatmiami]

/unhold