Run container UX issues

[mvolf]

There's a couple of UX issues related to the run container button:

1. The button is enabled even if a user didn't build an image. In this case the run container button should be disabled, since there's basically nothing to run.
2. If a user builds a project image but doesn't set the default project image, running the container is still possible but it fails with an exception:

Error during callback: com.github.dockerjava.api.exception.NotFoundException: Status 404: {"message":"pull access denied for [project_name], repository does not exist or may require 'docker login': denied: requested access to the resource is denied"}

Since the step for setting project image is obviously mandatory for a successful run, the UX for this should be more clear. A couple of suggestions:

• leave the run container button enabled, but when clicked show the modal window with a message that default project image was not set and ask the user if she/he wants to mark the latest image as default and run the container with it (preferred way, but a bit more complex to implement)
• disable the "run container" button if the default project image is not set and add a tooltip (on run button) which states that it's not possible to run the container without default project image

[mgubaidullin]

@mvolf is it on kubernetes or docker? could you please add screenshots?

[mvolf]

@mgubaidullin This is on docker, since only in docker user is able to build several project images and chose the default one. I'll post some screenshots as soon as I have some time.

[mvolf]

@mgubaidullin I just checked with the latest code from main branch. This is on docker and the "Deploy" button is enabled all of the time, even if user still didn't build the project or mark the default image for deployment. Since the "Deploy" button is always enabled user is able to click it and is in this case presented with an error.

Here's a few screenshots:

• user didn't build the project:

• error when user click deploy without the build (here it's also visible that the "Deploy" button is enabled):

• user builds the project but doesn't mark the newly created image as default:

• error when user click deploy without the default image (again "Deploy" button is enabled):

My conclusion is that the "Deploy" button should be enabled only if all requirements for the deployment are met. In other words, it should be enabled only if user built the project and marked the default image. Currently, user is presented with an error message which means nothing to them and is in fact very misleading.

[mgubaidullin]

There is a use case (from real project) for that. Project contains only application.properties and docker-compose.yaml User click Deploy button, select pull image if required to pull a new image and deploy it to Docker

[mvolf]

Oh, I wasn't aware of this. From where is this image being pulled in this case? How can we define which image to pull?

[mgubaidullin]

From the image tag in docker-compose.yaml https://github.com/apache/camel-karavan/blob/ad3a375e4109969eef864845beb612330ae8b340/karavan-app/src/main/resources/snippets/docker-compose.yaml#L3

[mvolf]

Thanks @mgubaidullin. Is there an ability to see from code if this image is defined. If there is, than it could be coded to disable the deployment button in case the project is not built, default image is not set and docker image is not defined.

[mgubaidullin]

Yes. This is feasible. We do not actually need to check if project is build. We could just check in image is set in docker-compose. If not set Deploy button should be disabled with tool tip 'Set project image'

[mvolf]

What if user sets the default image from the UI, but doesn't chose to commit these changes to git? Will the check in docker-compose be enough in this case?