NOTE: first, you may want to confirm that you can build your Dockerfile locally and if so, then move on to the following Velocity-specific troubleshooting steps as needed.
Docker builds can fail for any number of reasons, but Velocity-specific causes may be that the filepath to your Dockerfile or build context (i.e., the directory from which you would run the Docker build command locally) in the run configuration are incorrect. Check that the filepath to both the Dockerfile and the build context align with your current application.
If the above paths are correct, double check the accuracy the following elements if they are included in your Docker build process:
Why are my dependencies not being updated on image rebuild?
Velocity leverages advanced caching to speed up container image build times. Sometimes this caching will prevent packages that have been added during a Velocity session to be added to the remote container.
You can click the Code Sync button to override Velocity's caching, and rebuild your remote image from scratch based on your local source code.
When creating a run configuration, why isn't the Kubernetes context field being populated?
Velocity uses your Kubeconfig file to populate options in the Kubernetes context dropdown. This file is located by default at /.kube/config. Alternatively, a non-default filepath to your Kubeconfig can be set with the environment variable KUBECONFIG.
To confirm that the Kubeconfig is accessible, you can run the following in a terminal window: cat ~/.kube/config or cat $KUBECONFIG. If the file is accessible, you will see its contents printed to the terminal.
When creating a run configuration, why aren't the Kubernetes namespace and workload fields being populated?
Velocity requires the same cluster access as kubectl. If the Kubernetes namespace and workload fields aren't being populated when you create a Velocity run configuration, you may not have system-wide access to the cluster from your local machine, or you may not have permission to access a given namespace within the cluster.
To confirm that you have system-wide access from your local machine to your cluster, open a new terminal window and run kubectl get all -n <namespace>. If you don't see output that is similar to the following, you likely need to re-authenticate for Velocity to access your cluster environment, or you don't have permission to access the specified namespace.
Why is the Docker build process taking a long time?
Velocity's build process can be impacted by the size of your Docker image and your internet connection speed. If your build process is taking longer than expected, you may want to look at optimizing your Docker image, and confirming that your internet connection is stable.
What does the "operation cancelled, not enough resources available" error mean?
Velocity-specific resources, i.e. the builder and the registry, as well as any service that is spun up by Velocity during a development session, respect any resource quotas that may exist in your Kubernetes namespace. If resources aren't spinning up because a resource quota would be exceeded, you may need to adjust the configuration of your resource quota.
You can identify the specific resource that needs to be adjusted by reviewing the logs of your resource quota object, and you can learn more about resource quotas in the Kubernetes documentation.