Skaffold custom tests run after your application has been built and deployed, not during the build process itself.
Let’s say you’ve got a Kubernetes deployment and you want to run some integration tests against it after Skaffold deploys it. You can define these tests in your skaffold.yaml file.
Here’s a simple example of a skaffold.yaml with a custom test:
apiVersion: skaffold/v2beta29
kind: Config
build:
artifacts:
my-app:
docker:
dockerfile: Dockerfile
deploy:
kubectl:
manifests:
- k8s/*.yaml
test:
- image: my-app
structure:
- type: command
command: ["./scripts/run-integration-tests.sh"]
args: ["--app-url", "http://my-app.{{.Namespace}}.svc.cluster.local"]
In this configuration:
build: Defines how to build your container image. Here, it’s a simple Docker build.deploy: Specifies how to deploy your application to Kubernetes, usingkubectlwith manifests from thek8s/directory.test: This is where the magic happens for custom tests.image: my-app: This tells Skaffold which image built in thebuildsection this test is associated with. Skaffold will ensure this image is available before running the test.structure: Defines the type of test.-
type: command: We’re running a shell command. -
command: The actual command to execute. In this case, it’s a script namedrun-integration-tests.sh. -
args: Any arguments to pass to the command. Here, we’re passing the application’s URL. Notice the use of{{.Namespace}}. Skaffold will substitute the Kubernetes namespace it deployed to.
-
When you run skaffold dev, Skaffold will:
- Build your
my-appimage. - Deploy your application to Kubernetes.
- Once the deployment is ready, it will execute the command
./scripts/run-integration-tests.sh --app-url http://my-app.default.svc.cluster.local(assuming your namespace isdefault).
The test script scripts/run-integration-tests.sh might look something like this:
#!/bin/bash
APP_URL=$1
echo "Running integration tests against $APP_URL..."
# Replace with your actual test logic
if curl --fail "$APP_URL/health"; then
echo "Health check passed!"
else
echo "Health check failed!"
exit 1
fi
echo "Integration tests completed successfully."
exit 0
This script simply tries to curl a /health endpoint on your deployed application. If the curl command fails (e.g., the endpoint isn’t responding or returns an error code), the script exits with a non-zero status, which Skaffold interprets as a test failure. If it exits with 0, Skaffold considers the test successful.
Skaffold also supports other test types, like junit for Java projects, which can parse JUnit XML reports. You’d specify the path to these reports.
The power here is that Skaffold orchestrates the entire cycle: build, deploy, and test. If your custom tests fail, skaffold dev will halt, and you’ll see the output from your test script. This gives you immediate feedback on whether your application is not only deployed but also functional in its target environment.
The most surprising thing about Skaffold’s custom tests is that they don’t run inside the container image you just built. Skaffold executes them in the environment where you’re running skaffold dev (or skaffold run), typically your local machine or a CI runner, and it connects to your deployed Kubernetes cluster to perform the checks. This means your test script has access to your local tools and environment, not just what’s inside your application container.
If your custom tests are failing and skaffold dev keeps restarting, the next thing you’ll want to investigate is how Skaffold handles test failures and subsequent redeployments.