top | item 44999210

(no title)

justinsaccount | 6 months ago

I don't really have an opinion on using caddy in a container to serve a static site. That's fine, really.. However, the way the container is built is done in the worst possible way:

  # copy all files
  COPY . .

  # install Python with uv
  RUN uv python install 3.13

  # run build process
  RUN uv run --no-dev sus
This adds the entire repository to the first layer, then installs python, then runs the build which I assume will only then install the dependencies. This means that changing any file in the repository invalidates the first layer, triggering uv reinstalling python and all the dependencies again. The correct Dockerfile would be something like

  # install Python with uv
  RUN uv python install 3.13

  # copy info for dependencies
  COPY pyproject.toml uv.lock .

  # Install dependencies
  RUN uv whatever

  # Copy over everything else
  COPY . .

  # run build process
  RUN uv run --no-dev sus

discuss

order

nkantar|6 months ago

Author (not OP) here. It hadn’t really occurred to me to optimize the Dockerfile in this way because of how rarely the build is run in the first place, but I’m absolutely going to do this, since the ratio of code changes to content changes will definitely skew heavily toward the latter, and it just seems like a good habit anyway. Thanks for reminding me, and even explaining how to do it!

codespin|6 months ago

Getting the dockerfile order right is critical due to how docker caching works.

Even if you aren't an expert it is trivial these days to copy/paste it into chatGPT and ask it to optimize or suggest improvements to the dockerfile, it will then explain it to you.

globular-toast|6 months ago

My heuristic to go from least likely to change to most likely, bearing in mind dependencies, of course.

krick|6 months ago

Exactly. I wanted to also point this out in the relation of the author's desire to put all build commands in `just` configuration file. It sounds to me like a desire to use some another "slick and shiny tool" (which `just` is when compared to `make`), but what's the point exactly? The build-process will still be container-dependent and may or may not work outside of the container, and you don't get the benefit of Docker caching anymore.

simonw|6 months ago

Being able to run "just build" in a container-free local development environment and have the same build process run as the one in your production setup is a productivity boost worth having.

Same as how it's good to be able to easily run the exact same test suite in both dev and CI.