Why does my watched build command still run?
If you have configured Watch Files on a build command but it runs on every deployment -- even when none of the watched files changed -- the most common cause is that there is no build cache to restore.
Skipping requires a build cache
Watch Files has a second condition that is easy to miss: a build command is only skipped when the build cache can be restored onto the build server first.
This is deliberate. The purpose of skipping an install step is that its output -- your vendor/, node_modules/ or similar -- is already present on the build server. That output is only ever restored from the build cache. If we skipped the install when no cache was available, later steps would run against a missing dependency directory and fail.
So a command is skipped only when both are true:
- None of the changed files match the watch patterns, and
- Caching is enabled for the deployment and a cache file exists to restore.
If the second condition is not met, the command runs regardless of what changed.
The most common cause: no cached build files configured
If your project has no entries under Cached Build Files, no dependency files are stored between deployments, so there is nothing for a later deployment to restore. A watched build command will keep running on every deployment, and no change to your watch patterns will alter that.
To fix it, head to Build configuration within your project's Build Pipeline and add a cached file entry covering your dependency directory. For example:
vendor/**
for PHP and Composer, or:
node_modules/**
for Node. See Build Caching for the full setup.
The first deployment after adding a cached file entry will still run the command in full, because it has to populate the cache. Subsequent deployments will be able to skip it.
Other reasons a cache may be unavailable
Even with cached files configured, the cache may not be restorable on a given deployment:
- Use build cache? was disabled for that deployment under advanced settings, which requests a clean build.
- No usable dependency cache is available for this branch yet, so there is nothing to restore.
- The cache was cleaned up. Build caches are removed automatically after a period of inactivity, so a project that has not deployed for a while may no longer have one.
In each case the watched command runs rather than being skipped. This is the safe fallback, not an error.
Why so many files transferred afterwards
DeployHQ works out which files to transfer by comparing the finished build against the files it sent to the build server. When no cache was restored, your dependency directory is not part of that comparison, so every file produced by the install is treated as new rather than unchanged.
This is why a deployment that unexpectedly reinstalls dependencies can also transfer the entire dependency tree, even though the files are identical to those already on your server. Configuring a cached build file entry resolves both symptoms together.
Checking a specific deployment
Open the deployment and look at the Preparing stage. When a cache is restored you will see a Sending cached build to build server entry. If that entry is absent, no cache was available and any watched build command will have run.