fix(docker): default Dockerfile build context to code root (#5417)

[fliptrigga13]

Summary

Fixes #5417

Problem

In Dockerfile-type applications, when the Docker Context Path field was left empty, Dokploy fell back to:

const defaultContextPath = dockerFilePath.substring(0, dockerFilePath.lastIndexOf("/") + 1) || ".";

When a Dockerfile was placed in a subdirectory (e.g. docker/api/Dockerfile) in monorepos or multi-service projects, defaultContextPath set the build context to docker/api/ rather than the repository/application root (.), causing builds to fail whenever the Dockerfile attempted to COPY shared files from the repository root (e.g. COPY shared/config.json /app/config.json). This contradicted the UI field's documented placeholder (default: .) and differed from Docker Compose (context: .).

PR #5231 attempted to fix this, but in PR #5271 it was reverted because customGitBuildPath (such as in application.real.test.ts where customGitBuildPath = "/deno") was not accounted for in the context path calculation.

Solution

1. Extracted getApplicationBuildPath(application) in packages/server/src/utils/filesystem/directory.ts to consistently resolve the build path across all source providers (github, gitlab, bitbucket, gitea, drop, git).
2. Updated getDockerContextPath:
   • Safely incorporates buildPath alongside dockerContextPath.
   • Defaults to . (the application code root or buildPath sub-root) when dockerContextPath is empty or null, matching the UI placeholder and standard Docker Compose semantics.
   • Preserves custom relative context paths when explicitly set by the user.
3. Cleaned up getDockerCommand in packages/server/src/utils/builders/docker-file.ts to rely directly on getDockerContextPath.
4. Added unit test suite in apps/dokploy/__test__/deploy/docker-context-path.test.ts validating:
   • Root fallback when dockerContextPath is null/empty with subdirectory Dockerfiles (docker/api/Dockerfile).
   • Explicit dockerContextPath overrides.
   • Monorepo buildPath / customGitBuildPath scoping.
   • Remote build server path handling.

Confidence Score: 4/5

The PR should not merge until explicit Docker context paths retain backward-compatible resolution and the regression tests exercise the production implementation.

Summary

• The new default supports Dockerfiles in nested directories that copy repository-level files.
• Explicit persisted context paths are unintentionally rebased beneath buildPath, which can break existing deployments.
• The added tests duplicate the implementation instead of exercising the production resolver.

_{Reviews (1) · Last reviewed commit: "fix(docker): default Dockerfile build co..."}

[greptile-apps]

Explicit contexts are rebased

Prepending buildPath also rebases every explicitly configured dockerContextPath, although existing values were resolved from the repository code root. For example, an application with buildPath: "services/api" and a previously working context of "shared" now builds from code/services/api/shared instead of code/shared. If that nested path does not exist, the cd guard aborts the deployment. Apply buildPath only when selecting the default context, without changing the base of persisted explicit paths.

Suggested change

	buildPath ?? "",
	dockerContextPath || ".",
	dockerContextPath ? "" : buildPath ?? "",
	dockerContextPath || ".",

Knowledge Base Used: Build and Compose workflows

[greptile-apps]

Tests bypass production code

This test recreates the three production path resolvers locally, so every assertion exercises the copies rather than the changed exports in directory.ts. The suite can remain green if production behavior regresses or drifts from these copies. Import the production helpers through the existing @dokploy/server test alias and mock only their environmental dependencies.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!