Human summary: I was poking around trying to get the local dev environment to work, was enumerating the dockerfiles for fun, and copilot flagged that these 2 seem to be unused.
Summary
The repo contains two Dockerfiles that are not referenced by docker/docker-compose.yml, CI workflows, or any build script, and that have drifted out of sync with the active images. They appear to be early drafts that were superseded but never deleted, and they are misleading to anyone exploring the repo.
Files
1. docker/api/Dockerfile
- Zero references in the codebase — not in
docker/docker-compose.yml, .github/workflows/, azure-pipelines.yml, build_and_push_images.sh, or even docker/README.md.
- Looks like an early draft of
api/hastefuncapi/Dockerfile. Compared to the live one it is missing:
- Conda / GDAL 3.9.2 setup
- Installation of the
hastegeo package
entrypoint.sh → startup.py (which waits for Azurite and regenerates stats before starting the Functions host)
- Uses a relative
COPY ../../api/hastefuncapi/ . path that would not work with the build context used elsewhere in the repo.
2. docker/ui/Dockerfile
- The only reference is in
docker/README.md (line ~894), where it is literally annotated as "UI image (same as ui/Dockerfile)".
- Nothing builds it —
docker-compose.yml uses build: ../ui which resolves to ui/Dockerfile.
- It is also broken / stale on multiple counts:
FROM mcr.microsoft.com/azurelinux/base/nodejs:20.14 — Vite 8 (used by ui/package.json) requires Node ≥20.19 or ≥22.12, so this base image cannot start the dev server.COPY ../../UI/... uses a capitalized UI directory that does not exist in the repo.- Serves the built bundle on port 5000 via
serve -s dist, while the compose stack expects the UI on :4280 via SWA CLI.
Proposed action
- Delete both
docker/api/Dockerfile and docker/ui/Dockerfile.
- Remove the
docker/ui/Dockerfile row from the file-reference table in docker/README.md.
This is a cleanup-only change; no functional behavior should change because nothing builds either file today.
Human summary: I was poking around trying to get the local dev environment to work, was enumerating the dockerfiles for fun, and copilot flagged that these 2 seem to be unused.
Summary
The repo contains two Dockerfiles that are not referenced by
docker/docker-compose.yml, CI workflows, or any build script, and that have drifted out of sync with the active images. They appear to be early drafts that were superseded but never deleted, and they are misleading to anyone exploring the repo.Files
1.
docker/api/Dockerfiledocker/docker-compose.yml,.github/workflows/,azure-pipelines.yml,build_and_push_images.sh, or evendocker/README.md.api/hastefuncapi/Dockerfile. Compared to the live one it is missing:hastegeopackageentrypoint.sh→startup.py(which waits for Azurite and regenerates stats before starting the Functions host)COPY ../../api/hastefuncapi/ .path that would not work with the build context used elsewhere in the repo.2.
docker/ui/Dockerfiledocker/README.md(line ~894), where it is literally annotated as"UI image (same as ui/Dockerfile)".docker-compose.ymlusesbuild: ../uiwhich resolves toui/Dockerfile.FROM mcr.microsoft.com/azurelinux/base/nodejs:20.14— Vite 8 (used byui/package.json) requires Node ≥20.19 or ≥22.12, so this base image cannot start the dev server.COPY ../../UI/...uses a capitalizedUIdirectory that does not exist in the repo.serve -s dist, while the compose stack expects the UI on:4280via SWA CLI.Proposed action
docker/api/Dockerfileanddocker/ui/Dockerfile.docker/ui/Dockerfilerow from the file-reference table indocker/README.md.This is a cleanup-only change; no functional behavior should change because nothing builds either file today.