Improve error handling when there is no arm64 bundle/package support #459
Description
Environment
Device and OS:
Mac / Sonoma / M2 chip arm64
uds-cli version v0.9.1
k3d version v5.4.7
k3s version v1.25.6-k3s1 (default)
Steps to reproduce
- Reference Defense Unicorns packages in
uds-bundle.yamlwhich do not have support for arm64, only amd64. - Attempt to create the bundle with
uds create bundlesor by runninguds create <bundle-path> --confirm
Expected result
- I would expect that the bundle is either able to be built successfully or that I receive an error message that informs me that at least one of the desired packages is not available in the chosen architecture format. It would be helpful to know exactly which package is not supported in the event there are multiple packages which are being included in the bundle.
Actual Result
- I receive a go error. The go error at first glance appears to be an issue with tags/refs/formatting in the package. Yet when I specify amd64 as the architecture, I am able to build the bundle successfully without any errors. I can I check whether the equivalent arm64 packages are provided and see in this case, they do not exist. I can only determine that by going to the package registry in ghcr though and confirming.
I have checked the tag/refs and their formatting and those all appear to be okay.
Visual Proof (screenshots, videos, text, etc)
gavinscallon@Gavins-MacBook-Pro-2 dd-pipelines % uds create bundles
NOTE Saving log file to
/var/folders/37/qqg82c0x2hx43pczwp305f0r0000gn/T/uds-2024-02-23-11-10-02-4073448628.log
🎁 BUNDLE DEFINITION
kind: UDSBundle
metadata:
name: leapfrogai
description: A UDS bundle for deploying LeapfrogAI
version: 0.1.0
packages:
- name: leapfrogai-api
repository: ghcr.io/defenseunicorns/packages/leapfrogai-api
ref: dev
- name: leapfrog-ui
repository: ghcr.io/defenseunicorns/packages/leapfrog-ui
ref: dev3
- name: llama-cpp
repository: ghcr.io/decleaver/packages/leapfrogai/llama-cpp-python
ref: dev
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
? Create this bundle? Yes
⠴ Validating Bundle Package: leapfrogai-api (1s)
panic: no ':' separator in digest ""
goroutine 1 [running]:
github.com/opencontainers/go-digest.Digest.sepIndex({0x0, 0x0})
/home/runner/go/pkg/mod/github.com/opencontainers/go-digest@v1.0.0/digest.go:153 +0x90
github.com/opencontainers/go-digest.Digest.Encoded(...)
/home/runner/go/pkg/mod/github.com/opencontainers/go-digest@v1.0.0/digest.go:137
github.com/defenseunicorns/uds-cli/src/pkg/bundle.(*Bundle).ValidateBundleResources(0x140017b2000, 0x140017b2008, 0x0?)
/home/runner/work/uds-cli/uds-cli/src/pkg/bundle/common.go:144 +0x10f8
github.com/defenseunicorns/uds-cli/src/pkg/bundle.(*Bundle).Create(0x140017b2000)
/home/runner/work/uds-cli/uds-cli/src/pkg/bundle/create.go:47 +0x108
github.com/defenseunicorns/uds-cli/src/cmd.glob..func9(0x1078157a0?, {0x14001712920, 0x1, 0x10339c1fe?})
/home/runner/work/uds-cli/uds-cli/src/cmd/uds.go:60 +0xec
github.com/spf13/cobra.(*Command).execute(0x1078157a0, {0x140017128f0, 0x1, 0x1})
/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:987 +0x828
github.com/spf13/cobra.(*Command).ExecuteC(0x1078168e0)
/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115 +0x344
github.com/spf13/cobra.(*Command).Execute(...)
/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039
github.com/defenseunicorns/uds-cli/src/cmd.Execute()
/home/runner/work/uds-cli/uds-cli/src/cmd/root.go:60 +0x24
main.main()
/home/runner/work/uds-cli/uds-cli/main.go:19 +0x4c
Severity/Priority
Given that less production systems are running on arm64, I do not know how pressing of an issue this is.
Given the prevalence of MacOS in developer workflow these days, it would greatly enhance the usability of using uds-cli for local development if enhanced error handling/messaging. Developers would know they either need to build an equivalent arm64 package or else request that one be created for them.
Additional Context
Encountered this issue when setting up uds pipeline runners for a Dash Days project. I was not able to replicate the pipeline on my local machine without encountering errors during bundle creation.
Add any other context or screenshots about the technical debt here.