Can't deploy Zarf package built with images from insecure repo

[acdop100]

Environment
Device and OS: 2019 MacBook Pro, i9 16gb RAM, Big Sur 11.6
App version: 0.19.5
Kubernetes distro being used: minikube
Other:

Steps to reproduce

1. zarf package create --insecure
2. zarf package deploy --insecure

Expected result

Package deployment

Actual Result

  ✔  Creating port forwarding tunnel available at http://127.0.0.1:45001                                                                                                                        
DEBUG   config.GetSecret(registry-push)                                                                                                                                                       
DEBUG   0x2c36f40                                                                                                                                                                             
DEBUG   parsing reference "127.0.0.1:45001/zarfregistrytest:5000/gateway:latest": could not parse reference: 127.0.0.1:45001/zarfregistrytest:5000/gateway:latest                             
ERROR:  Unable to push the image to the registry

Visual Proof (screenshots, videos, text, etc)

Severity/Priority

Additional Context

Zarf successfully packages the images (or so it appears) with zarf package create. Unfortunately I cannot deploy the package on the same machine the package is created on. I haven't tried a separate machine but I would expect the same result.

If the Zarf package contains images that were not pulled from the local reg (i.e. docker hub) it copies those fine; it only fails when it tries to copy the local images. It doesn't matter if the images were built locally, tagged, and pushed to the registry or pulled from outside, tagged, and pushed to local registry (tested with busybox).

[jeff-mccoy]

Looking at this, it looks like the issues is in the image path rewrite on deploy, it's not accounting for the alternate port properly.

[acdop100]

Is there a way for me to fix this? Or mitigate it for now?

[jeff-mccoy]

Looking at it now

[jeff-mccoy]

quick question--do you see the same issue if you have a dotted host portion: 127.0.0.1 or somedomain.test for example? Part of the issue here is that docker allows implicit dockerhub paths so it's hard to determine if gitea/gitea:tag is on dockerhub or actually on a server called gitea.

[jeff-mccoy]

For reference, here's the regex used to find the parts: https://regex101.com/r/PiL191/1. You can add your own entries to test there.

[acdop100]

I'm reinstalling some dev tools, so i'll test them as soon as I can. I am simultaneously about to test my package in a linux VM and see if that performs any differently. If it does i'll be pretty confused.

[JasonvanBrackel]

@acdop100 @jeff-mccoy I this stale, fixed or need a 2nd look?

[JasonvanBrackel]

Whoever picks this up start with #666

[JasonvanBrackel]

@YrrepNoj Assigning you since you're working #666

[jeff-mccoy]

We should verify this is still an issue after the next release that includes #876

[Racer159]

Fixed in #1280