add dockerignore

[lasteris]

Added .dockergnore file to eliminate trash in image

[JarvisCraft]

(Un?)popular opinion: you may even go with excluding everything and including the specific parts needed

[vadv]

Thanks for the PR, @lasteris — having a .dockerignore is a great idea, the build context is definitely larger than it needs to be. And @JarvisCraft is spot on with the whitelist suggestion.

I'd suggest going with the "exclude everything, allow only what's needed" approach. Right now the blacklist still lets through quite a few directories that aren't needed for cargo build --release — tests/ alone can be tens of megabytes (Go, Python, .NET test suites, SQL fixtures), plus documentation/, fuzz/, example/, debian/, .venv/, etc.

Here's what the Dockerfile actually needs:

• Cargo.toml + Cargo.lock — project manifest and lockfile
• rust-toolchain.toml — pinned Rust version
• src/ — source code (both pg_doorman and patroni_proxy)
• patches/ — patched crate used via [replace] in Cargo.toml
• benches/ and tests/bdd/main.rs — referenced in [[bench]] and [[test]] sections; Cargo validates these exist when parsing the manifest, even for a release build

Suggested .dockerignore:

# Exclude everything by default
*

# Cargo manifest & lockfile
!Cargo.toml
!Cargo.lock

# Rust toolchain
!rust-toolchain.toml

# Source code
!src/
!src/**

# Patched crates ([replace] in Cargo.toml)
!patches/
!patches/**

# Cargo requires [[bench]] and [[test]] sources to exist at manifest parse time
!benches/
!benches/**
!tests/bdd/main.rs

This way any new files or directories added to the repo in the future are automatically excluded from the Docker context — no need to remember to update .dockerignore each time.

[lasteris]

Thank you both @JarvisCraft and @vadv for replies
commit updated with last suggestions :)

[vadv]

Oh, and @JarvisCraft — great call on the whitelist approach. That's exactly the right way to do it: new files are excluded by default, no need to remember to update .dockerignore every time.

But this has a flip side worth protecting against. With the whitelist, if someone adds a new file needed for the build (a new [[bench]], a [patch] crate, a build script), it won't be in the context either — and the Docker build will silently break. Currently build-packages.yaml only builds the image on release tags (v*.*.*), so we'd only find out at the worst possible moment.

I think it makes sense to add a lightweight CI check on PRs:

      - name: Verify Docker build context
        run: docker build --target builder .

--target builder stops right after COPY . /app + cargo build — that's the only stage where .dockerignore matters. The final image (debian-slim + binary) isn't even touched. No need to write a separate Dockerfile — this is fast enough for a PR check and catches .dockerignore drift early.

@lasteris would you mind adding this as a separate workflow? Or we can do it in a follow-up PR.

[lasteris]

Updated workflow operated success, so i can assume we are fine now :)
Thank you @vadv