Fix hud debug dockerfile.hud error

[ryantzr1]

Fix hud debug . to correctly identify and use Dockerfile.hud instead of only Dockerfile.

This resolves the issue where the hud debug command failed because it was hardcoded to look for Dockerfile, even when Dockerfile.hud (the preferred HUD-specific Dockerfile) was present. The changes update the environment detection and build logic to prioritize Dockerfile.hud and fall back to Dockerfile.

---

Linear Issue: HUD-592

 

---

Note

Prioritizes HUD-specific Dockerfiles and improves directory handling for debug/build flows.

• debug detects directory mode by finding Dockerfile.hud or Dockerfile via find_dockerfile and no longer requires pyproject.toml
• build_environment now uses find_dockerfile and passes -f when using non-standard Dockerfile.hud; logs which Dockerfile is used
• New find_dockerfile utility; is_environment_directory updated to accept Dockerfile.hud as valid
• Tests added for find_dockerfile, is_environment_directory with Dockerfile.hud, and hud debug . working with only Dockerfile.hud

^{Written by Cursor Bugbot for commit 1f2b32f. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[ryantzr1]

HUD Bugbot review:

Summary: Prefer Dockerfile.hud in debug/build flows, add find_dockerfile, and expand tests so hud debug . works when only Dockerfile.hud is present.

Findings:

• Title: hud debug directory mode no longer validates pyproject.toml
  • Severity: medium
  • File: hud/cli/__init__.py
  • Description: The previous implementation used is_environment_directory, which enforced both a Dockerfile and a pyproject.toml, helping ensure the target directory was a full HUD environment. The new logic only checks that the path is a directory with any Dockerfile (via find_dockerfile), so hud debug <dir> may now treat arbitrary directories that happen to contain a Dockerfile (but are not configured HUD environments) as valid debug environments. This could lead to confusing behavior or unexpected images being used.
  • Suggestion: If the goal is to support Dockerfile.hud without requiring pyproject.toml for debug, consider introducing a more explicit helper (e.g., is_debuggable_directory) that represents the desired conditions: allow Dockerfile.hud-only directories, but still avoid treating generic Dockerfile-only directories as HUD environments. At minimum, consider keeping the pyproject.toml requirement for standard Dockerfile-based directories, and add tests around directories that only contain a generic Dockerfile.

[ryantzr1]

HUD Bugbot review:

Summary: Updates debug/environment utilities to prefer Dockerfile.hud over Dockerfile, and relaxes hud debug directory detection to only require a Dockerfile. Adds tests for the new behavior.

Findings:

• Title: Directory-mode debug now ignores pyproject.toml and src checks
  Severity: medium
  File: hud/cli/__init__.py
  Description: hud debug <dir> previously relied on is_environment_directory, which enforced both a Dockerfile and pyproject.toml, aligning with the environment directory contract. The new logic only checks for a directory containing a Dockerfile via find_dockerfile, so any directory with a Dockerfile is now treated as an environment directory, even if it lacks pyproject.toml or expected structure. This broadens behavior and can surprise users or diverge from other flows that still assume an environment directory has pyproject.toml.
  Suggestion: If the intent is to make hud debug more permissive, call that out explicitly (in docs or help text) and/or introduce a dedicated helper (e.g., is_debug_environment_directory) that encodes the relaxed rules, so the contract is clear and consistent. Otherwise, consider continuing to use is_environment_directory (already updated to support Dockerfile.hud).

• Title: build_environment silently assumes directory exists and is a directory
  Severity: low
  File: hud/cli/utils/environment.py
  Description: build_environment now calls find_dockerfile(Path(directory)) without checking that directory exists or is a directory. If callers pass a non-existent or non-directory path, find_dockerfile returns None and docker build runs with default Dockerfile resolution, which can lead to confusing behavior instead of a clear error.
  Suggestion: Add a precondition check (e.g., dir_path.is_dir()) and either raise a descriptive exception or log an error and return False when the given directory is invalid. Optionally reuse is_environment_directory or a lighter-weight check to ensure the directory has at least minimal expected structure before building.

[lorenss-m]

We have a helper in hud.cli.build that does the exact same:
def find_dockerfile(directory: Path) -> Path | None: