Build failures
A build failure stops the deployment before a revision exists. The page is titled Build failed, the Build log holds what happened, and the deployment that was serving keeps serving. Builds explains what a build does; this page is what to do when it does not.
The Dockerfile Kuppit was told to build no longer exists
The service's Dockerfile path names a file the commit does not contain. Either the Dockerfile was moved or removed, or the Root directory changed and the path is now wrong relative to it.
Open the service's Settings. If the Dockerfile moved, correct the path; if it was removed on purpose, choose Inspect latest and let Kuppit detect an automatic build instead. Then redeploy.
Build settings no longer match the repository
The commit changed shape since the build settings were saved: a Dockerfile appeared where there was none, the framework changed, or the manifest Kuppit detected from is gone. Kuppit refuses to build with settings it knows are stale rather than guess.
Open the service's Settings, choose Inspect latest, review what Kuppit detected from the newest commit, and save. Kuppit never re-detects on its own; a saved inspection is what makes the settings current again.
The repository is too large for Kuppit to build
Kuppit reads a repository up to 20,000 files and gives up extracting after 60 seconds. This is usually a repository with generated output, vendored dependencies or media committed.
Narrow the Root directory to the application if the rest of the repository is not needed to build it, or remove what should not be in Git. Symbolic links are never followed, so they do not count.
The repository source could not be read
The archive Kuppit fetched from GitHub was malformed. It is rare and usually transient.
Push again, or Redeploy. If it repeats on the same commit, look for files Git can represent but an archive cannot, and for a repository that is mid-rewrite.
The build failed
Your build command, or a step of your Dockerfile, exited with an error. Kuppit has nothing to add beyond the output.
Open the Build log with View relevant logs. Infrastructure lines are hidden by default so the last thing before the error is usually yours. The common causes:
- A dependency that does not install: a lockfile out of step with
package.json, a package manager version the lockfile needs, a private package with no credentials. - A build script that assumes a variable. Build-time configuration is not the service's variables; a build that needs one must not depend on it, or must read a value committed to the repository.
- A Dockerfile that copies a path that does not exist in the build context, which is the Root directory.
Fix it in the repository and push. Redeploy builds the same commit again and fails the same way unless the cause was transient.
The build ran out of time
A build has 15 minutes. Beyond that Kuppit stops it.
Check the Build log for where the time went. A Dockerfile that reinstalls everything on every build is the usual reason; order the Dockerfile so dependency installation is cached ahead of copying the source. An automatic build caches dependencies between builds on its own.