devspace | Get top posts from the best developer platforms | iOS library

Ok, I think I have it sorted out now and the pipeline stages are running successfully. It was a combination of adding DOCKER_BUILDKIT: 1 like:

Yes, you should be using the after:initialSync:* hook, i.e. if your sql dump file is part of the file sync, it will be uploaded during initialSync, then the hook can be used to import the dump.

You will need a post-sync hook for this, which is separate from the DevSpace lifecycle hooks. You can define it with the dev.sync directly and it looks like this:

Try devspace enter --image-selector ${APP-NAME}/${API-DEV} -- bash -c "YOUR_BASH_COMMANDS_HERE"

-- makes sure that all flags afterwards are not meant to be flags for devspace enter and bash -c STRING starts a shell and passes the STRING as commands to be run in this shell.

To debug this, you may want to run devspace render which shows the plain manifests that DevSpace generates from the Helm chart before deploying them to the cluster. That way you can see what is different compared to your skaffold manifests. Alternatively, you could check inside the cluster using these commands:

Kind of important step being left off of the Django tutorial. After running devspace dev, you need to run in the devspace CLI that comes up:

Directories do not have a size. If you want to calculate how much space is used by a directory, loop through and aggregate the file sizes within

You can try below commands

Removing untagged images:

Copying my response to this from Reddit to help others who may look for this on StackOverflow:

DevSpace maintainer here. For my workflow (and the default DevSpace behavior if you set it up with devspace init), image building is being skipped during development because it tends to be the most annoying and time-consuming part of the workflow. Instead, most teams that use DevSpace have a dev image pushed to a registry and build by CI/CD which is then used in devspace.yaml using replacePods.replaceImage as shown here: https://devspace.sh/cli/docs/configuration/development/replace-pods

This means that your manifests or helm charts are being deployed referencing the prod images (as they should be) and then devspace will (after deployment) replace the images of your pods with dev-optimized images that ship all your tooling. Inside these pods, you can then use the terminal to build your application, run tests along with other dependencies running in your cluster etc.

However, typically teams also start using DevSpace in CI/CD after a while and then they add profiles (e.g. prod profile or integration-testing profile etc. - more on https://devspace.sh/cli/docs/configuration/profiles/basics) to their devspace.yaml where they add image building again because they want to build the images in their pipelines using kaniko or docker. For this, you would specify the build target in devspace.yaml as well: https://devspace.sh/cli/docs/configuration/images/docker#target

FWIW regarding 1: I never use docker run --target but I also always use Kubernetes directly over manual docker commands to run any workloads.