Validate --builder-image name prior staging

[mmartin24]

Issue

I tried to push the following command and it errors on the image name

epinio push --builder-image "paketobuildpacks/builder:*" -n sampleapp -p /home/mmartin/suse/epinio-repos/epinio/assets/sample-app 

Note: this does not happen for instance with the following one:

epinio push --builder-image 'paketobuildpacks/builder:full' -n sampleapp5 -p /home/mmartin/suse/epinio-repos/epinio/assets/sample-app

Observed behavior

The app starts to be pushed and gets hanged in the staging process silently.
Later when looking at the pod I see error status InvalidImageName:

k get pod stage-workspace-sample-d6580f3080dbe5ec533ad21719bda1b5976z28w9 -n epinio -o wide
NAME                                                              READY   STATUS             RESTARTS   AGE   IP           NODE                             NOMINATED NODE   READINESS GATES
stage-workspace-sample-d6580f3080dbe5ec533ad21719bda1b5976z28w9   0/1     InvalidImageName   0          16m   10.42.0.89   k3d-epinio-acceptance-server-0   <none>           <none>

Looking at the description of the error I see:

Warning  InspectFailed  24s (x25 over 5m25s)   kubelet            Failed to apply default image tag "paketobuildpacks/builder:*": couldn't parse image reference "paketobuildpacks/builder:*": invalid reference format   

Proposed behavior

• Verify before pushing staging image name is valid
• Perhaps suggest an example how it should be

Test info

➜  ~ epinio info                                                                                                                           

✔️  Epinio Environment
Platform: k3s
Kubernetes Version: v1.26.10+k3s2
Epinio Server Version: v1.11.0-rc1
Epinio Client Version: v1.11.0-rc1
OIDC enabled: true

[andreas-kupries]

This is a tricky thing ... The silent hanging is a definitive issue, we should report better. Not sure however if we can. That needs research into K pods and monitoring them. IOW, instead of just setting up log streaming the server may have to perform additional observation of the container start process to see issues which happen before the logs become available.

Exact validation may require to actually (attempt to) pull the image by the E server before it uses it in the staging job.
That could be bad (multi-GB download, maybe abortable?).

Some validation could be done to reject clearly illegal strings, i.e. like * in the example, as it is a glob-pattern.
This however is not a true solution, as the user can still enter syntactically legal tags, which simply do not exist.
That then causes the same issue as reported.

[enrichman]

We need a more complete understanding of the current status of the staging job (if it failed, still running and so on). Maybe the StagingComplete endpoint can be used for this. This is also probably needed to get the "current state" of the deployments, related to the #593 issue.