fix(ci): build the API image from the repository root

[nadeem4]

The failure

The ghcr job was the only leg of run 33198050069 to fail on the v0.1.0 release. All three packages reached PyPI, the tag, the GitHub Release and the versioned docs all succeeded; only the image build did not:

"/packages/adapter-sdk": not found
"/packages/api": not found
"/packages/nl2sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key

Cause: the build context does not match the Dockerfile's COPY paths

packages/api/Dockerfile installs the three packages from their local sources and writes its COPY paths relative to the repository root:

COPY ./packages/adapter-sdk /app/packages/adapter-sdk
COPY ./packages/nl2sql /app/packages/nl2sql
COPY ./packages/api /app/packages/api

COPY resolves against the build context, and the workflow set context: packages/api. So buildx looked for packages/api/packages/adapter-sdk, which does not exist — hence "not found" for all three.

The Dockerfile was changed in Task 13 to install from local paths (nothing was on PyPI yet); the workflow's context was never updated to match. The demo stack has had this right all along — packages/nl2sql/src/nl2sql/cli/demo/schemas.py generates context: .. with dockerfile: packages/api/Dockerfile. The workflow was the outlier.

The fix points the context at the repository root and names the Dockerfile explicitly (both are documented inputs of docker/build-push-action@v6):

context: .file: packages/api/Dockerfile

The stale comment above the job — which claimed the Dockerfile installs from PyPI — is corrected. needs: pypi is kept deliberately, but for a different reason than before: the image build no longer depends on PyPI, so the dependency now only ensures the image is published for a release that actually reached PyPI.

The .dockerignore is new, and why

There was no .dockerignore at the repo root or in packages/api. With context: ., the entire working tree is sent to the daemon. On CI the checkout is clean so it would have worked, but it is wasteful there and slow-to-broken on a developer machine, where the tree includes .venv-dev/ (857 MB), chroma_db/ (94 MB), site/, data/, logs/, .git/, __pycache__/ and stale build/, dist/ and *.egg-info directories — 993 MB in total on this checkout.

The ignore list was chosen against what the build actually needs. Only packages/adapter-sdk, packages/nl2sql and packages/api are COPYed, so of the three manifests:

• packages/nl2sql/pyproject.toml declares readme = "README.md", and packages/nl2sql/README.md must survive — a missing readme fails the wheel build. It is not excluded, and the built image's nl2sql-engine metadata carries Description-Content-Type: text/markdown with the README body, which proves it was picked up.
• packages/adapter-sdk/pyproject.toml declares no readme and the package has no README.md.
• packages/api/pyproject.toml declares no readme (it has a README.md, but nothing references it).

Patterns are matched against the path relative to the context root, so repo-level directories are named directly and anything that also appears inside a package (build, dist, *.egg-info, __pycache__, .pytest_cache) is prefixed with **/. data/ is excluded safely — the demo stack bind-mounts it at run time, it is never copied at build time.

Local build evidence

CI cannot verify this: no workflow builds the image on a PR. The verification is a local build from a clean context.

docker build -f packages/api/Dockerfile -t nl2sql-api:test .

• Result: succeeds (BUILD_EXIT=0). Same command failed with the "not found" error before, using the old context.
• Context transferred:890.43 kB (plus a 1.06 kB .dockerignore), down from a 993 MB working tree.
• Final image size: 1.67 GB.
• Installed from local sources, not PyPI — the build log shows Processing ./packages/adapter-sdk, Processing ./packages/nl2sql, Processing ./packages/api, then Building wheel for nl2sql-adapter-sdk / nl2sql-engine / nl2sql-api (pyproject.toml). There is no Downloading nl2sql... line anywhere.

$ docker run --rm nl2sql-api:test python -c "import nl2sql, nl2sql_api; print('ok')"
ok
$ docker run --rm nl2sql-api:test pip show nl2sql-engine | head -3
Name: nl2sql-engine
Version: 0.1.0
Summary: Natural-language-to-SQL engine, CLI and database adapters

nl2sql-api and nl2sql-adapter-sdk are also 0.1.0. The [postgres,mysql] extras resolved (import psycopg2, pymysql succeeds) and nl2sql --help runs. Starting the container reaches uvicorn and application startup, then stops at datasource configuration, which is expected — the image needs configs/ and live databases mounted at run time, exactly as the demo stack provides.

Nothing was pushed, dispatched, re-run or tagged.

Docs

• docs/development/releasing.md — the ghcr step described the Dockerfile as installing from PyPI. Corrected, with the context requirement and the reason needs: pypi stays.
• docs/getting_started/docker.md — already told readers to build from the repo root; it now says why, and describes the new .dockerignore.
• docs/deployment/docker.md needed no change: it covers deploying the service, not building the image.

mkdocs build --strict is clean, from a throwaway venv built from requirements-docs.txt.

Baselines

Unchanged: unit 231 passed, 1 skipped, 47 deselected; key-free integration 28 passed.

Out of scope, reported not fixed

packages/api/Dockerfile.dev is genuinely broken and is not touched here. Ten of its twenty COPY lines reference paths deleted in the Task 10 packaging collapse — packages/core, packages/adapter-sqlalchemy and packages/adapters/{mssql,mysql,postgres,sqlite} — and a build fails the same way this bug did:

ERROR: failed to solve: failed to compute cache key: ... "/packages/adapters/sqlite/src": not found

Nothing references it: no workflow, no compose file, no doc, and no code path. It should be deleted, but that is a separate decision and a separate PR.

[nadeem4]

The failure

The ghcr job was the only leg of run 33198050069 to fail on the v0.1.0 release. All three packages reached PyPI, the tag, the GitHub Release and the versioned docs all succeeded; only the image build did not:

"/packages/adapter-sdk": not found
"/packages/api": not found
"/packages/nl2sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key

Cause: the build context does not match the Dockerfile's COPY paths

packages/api/Dockerfile installs the three packages from their local sources and writes its COPY paths relative to the repository root:

COPY ./packages/adapter-sdk /app/packages/adapter-sdk
COPY ./packages/nl2sql /app/packages/nl2sql
COPY ./packages/api /app/packages/api

COPY resolves against the build context, and the workflow set context: packages/api. So buildx looked for packages/api/packages/adapter-sdk, which does not exist — hence "not found" for all three.

The Dockerfile was changed in Task 13 to install from local paths (nothing was on PyPI yet); the workflow's context was never updated to match. The demo stack has had this right all along — packages/nl2sql/src/nl2sql/cli/demo/schemas.py generates context: .. with dockerfile: packages/api/Dockerfile. The workflow was the outlier.

The fix points the context at the repository root and names the Dockerfile explicitly (both are documented inputs of docker/build-push-action@v6):

context: .file: packages/api/Dockerfile

The stale comment above the job — which claimed the Dockerfile installs from PyPI — is corrected. needs: pypi is kept deliberately, but for a different reason than before: the image build no longer depends on PyPI, so the dependency now only ensures the image is published for a release that actually reached PyPI.

The .dockerignore is new, and why

There was no .dockerignore at the repo root or in packages/api. With context: ., the entire working tree is sent to the daemon. On CI the checkout is clean so it would have worked, but it is wasteful there and slow-to-broken on a developer machine, where the tree includes .venv-dev/ (857 MB), chroma_db/ (94 MB), site/, data/, logs/, .git/, __pycache__/ and stale build/, dist/ and *.egg-info directories — 993 MB in total on this checkout.

The ignore list was chosen against what the build actually needs. Only packages/adapter-sdk, packages/nl2sql and packages/api are COPYed, so of the three manifests:

• packages/nl2sql/pyproject.toml declares readme = "README.md", and packages/nl2sql/README.md must survive — a missing readme fails the wheel build. It is not excluded, and the built image's nl2sql-engine metadata carries Description-Content-Type: text/markdown with the README body, which proves it was picked up.
• packages/adapter-sdk/pyproject.toml declares no readme and the package has no README.md.
• packages/api/pyproject.toml declares no readme (it has a README.md, but nothing references it).

Patterns are matched against the path relative to the context root, so repo-level directories are named directly and anything that also appears inside a package (build, dist, *.egg-info, __pycache__, .pytest_cache) is prefixed with **/. data/ is excluded safely — the demo stack bind-mounts it at run time, it is never copied at build time.

Local build evidence

CI cannot verify this: no workflow builds the image on a PR. The verification is a local build from a clean context.

docker build -f packages/api/Dockerfile -t nl2sql-api:test .

• Result: succeeds (BUILD_EXIT=0). Same command failed with the "not found" error before, using the old context.
• Context transferred:890.43 kB (plus a 1.06 kB .dockerignore), down from a 993 MB working tree.
• Final image size: 1.67 GB.
• Installed from local sources, not PyPI — the build log shows Processing ./packages/adapter-sdk, Processing ./packages/nl2sql, Processing ./packages/api, then Building wheel for nl2sql-adapter-sdk / nl2sql-engine / nl2sql-api (pyproject.toml). There is no Downloading nl2sql... line anywhere.

$ docker run --rm nl2sql-api:test python -c "import nl2sql, nl2sql_api; print('ok')"
ok
$ docker run --rm nl2sql-api:test pip show nl2sql-engine | head -3
Name: nl2sql-engine
Version: 0.1.0
Summary: Natural-language-to-SQL engine, CLI and database adapters

nl2sql-api and nl2sql-adapter-sdk are also 0.1.0. The [postgres,mysql] extras resolved (import psycopg2, pymysql succeeds) and nl2sql --help runs. Starting the container reaches uvicorn and application startup, then stops at datasource configuration, which is expected — the image needs configs/ and live databases mounted at run time, exactly as the demo stack provides.

Nothing was pushed, dispatched, re-run or tagged.

Docs

• docs/development/releasing.md — the ghcr step described the Dockerfile as installing from PyPI. Corrected, with the context requirement and the reason needs: pypi stays.
• docs/getting_started/docker.md — already told readers to build from the repo root; it now says why, and describes the new .dockerignore.
• docs/deployment/docker.md needed no change: it covers deploying the service, not building the image.

mkdocs build --strict is clean, from a throwaway venv built from requirements-docs.txt.

Baselines

Unchanged: unit 231 passed, 1 skipped, 47 deselected; key-free integration 28 passed.

Out of scope, reported not fixed

packages/api/Dockerfile.dev is genuinely broken and is not touched here. Ten of its twenty COPY lines reference paths deleted in the Task 10 packaging collapse — packages/core, packages/adapter-sqlalchemy and packages/adapters/{mssql,mysql,postgres,sqlite} — and a build fails the same way this bug did:

ERROR: failed to solve: failed to compute cache key: ... "/packages/adapters/sqlite/src": not found

Nothing references it: no workflow, no compose file, no doc, and no code path. It should be deleted, but that is a separate decision and a separate PR.

[nadeem4]

The failure

The ghcr job was the only leg of run 33198050069 to fail on the v0.1.0 release. All three packages reached PyPI, the tag, the GitHub Release and the versioned docs all succeeded; only the image build did not:

"/packages/adapter-sdk": not found
"/packages/api": not found
"/packages/nl2sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key

Cause: the build context does not match the Dockerfile's COPY paths

packages/api/Dockerfile installs the three packages from their local sources and writes its COPY paths relative to the repository root:

COPY ./packages/adapter-sdk /app/packages/adapter-sdk
COPY ./packages/nl2sql /app/packages/nl2sql
COPY ./packages/api /app/packages/api

COPY resolves against the build context, and the workflow set context: packages/api. So buildx looked for packages/api/packages/adapter-sdk, which does not exist — hence "not found" for all three.

The Dockerfile was changed in Task 13 to install from local paths (nothing was on PyPI yet); the workflow's context was never updated to match. The demo stack has had this right all along — packages/nl2sql/src/nl2sql/cli/demo/schemas.py generates context: .. with dockerfile: packages/api/Dockerfile. The workflow was the outlier.

The fix points the context at the repository root and names the Dockerfile explicitly (both are documented inputs of docker/build-push-action@v6):

context: .file: packages/api/Dockerfile

The stale comment above the job — which claimed the Dockerfile installs from PyPI — is corrected. needs: pypi is kept deliberately, but for a different reason than before: the image build no longer depends on PyPI, so the dependency now only ensures the image is published for a release that actually reached PyPI.

The .dockerignore is new, and why

There was no .dockerignore at the repo root or in packages/api. With context: ., the entire working tree is sent to the daemon. On CI the checkout is clean so it would have worked, but it is wasteful there and slow-to-broken on a developer machine, where the tree includes .venv-dev/ (857 MB), chroma_db/ (94 MB), site/, data/, logs/, .git/, __pycache__/ and stale build/, dist/ and *.egg-info directories — 993 MB in total on this checkout.

The ignore list was chosen against what the build actually needs. Only packages/adapter-sdk, packages/nl2sql and packages/api are COPYed, so of the three manifests:

• packages/nl2sql/pyproject.toml declares readme = "README.md", and packages/nl2sql/README.md must survive — a missing readme fails the wheel build. It is not excluded, and the built image's nl2sql-engine metadata carries Description-Content-Type: text/markdown with the README body, which proves it was picked up.
• packages/adapter-sdk/pyproject.toml declares no readme and the package has no README.md.
• packages/api/pyproject.toml declares no readme (it has a README.md, but nothing references it).

Patterns are matched against the path relative to the context root, so repo-level directories are named directly and anything that also appears inside a package (build, dist, *.egg-info, __pycache__, .pytest_cache) is prefixed with **/. data/ is excluded safely — the demo stack bind-mounts it at run time, it is never copied at build time.

Local build evidence

CI cannot verify this: no workflow builds the image on a PR. The verification is a local build from a clean context.

docker build -f packages/api/Dockerfile -t nl2sql-api:test .

• Result: succeeds (BUILD_EXIT=0). Same command failed with the "not found" error before, using the old context.
• Context transferred:890.43 kB (plus a 1.06 kB .dockerignore), down from a 993 MB working tree.
• Final image size: 1.67 GB.
• Installed from local sources, not PyPI — the build log shows Processing ./packages/adapter-sdk, Processing ./packages/nl2sql, Processing ./packages/api, then Building wheel for nl2sql-adapter-sdk / nl2sql-engine / nl2sql-api (pyproject.toml). There is no Downloading nl2sql... line anywhere.

$ docker run --rm nl2sql-api:test python -c "import nl2sql, nl2sql_api; print('ok')"
ok
$ docker run --rm nl2sql-api:test pip show nl2sql-engine | head -3
Name: nl2sql-engine
Version: 0.1.0
Summary: Natural-language-to-SQL engine, CLI and database adapters

nl2sql-api and nl2sql-adapter-sdk are also 0.1.0. The [postgres,mysql] extras resolved (import psycopg2, pymysql succeeds) and nl2sql --help runs. Starting the container reaches uvicorn and application startup, then stops at datasource configuration, which is expected — the image needs configs/ and live databases mounted at run time, exactly as the demo stack provides.

Nothing was pushed, dispatched, re-run or tagged.

Docs

• docs/development/releasing.md — the ghcr step described the Dockerfile as installing from PyPI. Corrected, with the context requirement and the reason needs: pypi stays.
• docs/getting_started/docker.md — already told readers to build from the repo root; it now says why, and describes the new .dockerignore.
• docs/deployment/docker.md needed no change: it covers deploying the service, not building the image.

mkdocs build --strict is clean, from a throwaway venv built from requirements-docs.txt.

Baselines

Unchanged: unit 231 passed, 1 skipped, 47 deselected; key-free integration 28 passed.

Out of scope, reported not fixed

packages/api/Dockerfile.dev is genuinely broken and is not touched here. Ten of its twenty COPY lines reference paths deleted in the Task 10 packaging collapse — packages/core, packages/adapter-sqlalchemy and packages/adapters/{mssql,mysql,postgres,sqlite} — and a build fails the same way this bug did:

ERROR: failed to solve: failed to compute cache key: ... "/packages/adapters/sqlite/src": not found

Nothing references it: no workflow, no compose file, no doc, and no code path. It should be deleted, but that is a separate decision and a separate PR.

[nadeem4]

The failure

The ghcr job was the only leg of run 33198050069 to fail on the v0.1.0 release. All three packages reached PyPI, the tag, the GitHub Release and the versioned docs all succeeded; only the image build did not:

"/packages/adapter-sdk": not found
"/packages/api": not found
"/packages/nl2sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key

Cause: the build context does not match the Dockerfile's COPY paths

packages/api/Dockerfile installs the three packages from their local sources and writes its COPY paths relative to the repository root:

COPY ./packages/adapter-sdk /app/packages/adapter-sdk
COPY ./packages/nl2sql /app/packages/nl2sql
COPY ./packages/api /app/packages/api

COPY resolves against the build context, and the workflow set context: packages/api. So buildx looked for packages/api/packages/adapter-sdk, which does not exist — hence "not found" for all three.

The Dockerfile was changed in Task 13 to install from local paths (nothing was on PyPI yet); the workflow's context was never updated to match. The demo stack has had this right all along — packages/nl2sql/src/nl2sql/cli/demo/schemas.py generates context: .. with dockerfile: packages/api/Dockerfile. The workflow was the outlier.

The fix points the context at the repository root and names the Dockerfile explicitly (both are documented inputs of docker/build-push-action@v6):

context: .file: packages/api/Dockerfile

The stale comment above the job — which claimed the Dockerfile installs from PyPI — is corrected. needs: pypi is kept deliberately, but for a different reason than before: the image build no longer depends on PyPI, so the dependency now only ensures the image is published for a release that actually reached PyPI.

The .dockerignore is new, and why

There was no .dockerignore at the repo root or in packages/api. With context: ., the entire working tree is sent to the daemon. On CI the checkout is clean so it would have worked, but it is wasteful there and slow-to-broken on a developer machine, where the tree includes .venv-dev/ (857 MB), chroma_db/ (94 MB), site/, data/, logs/, .git/, __pycache__/ and stale build/, dist/ and *.egg-info directories — 993 MB in total on this checkout.

The ignore list was chosen against what the build actually needs. Only packages/adapter-sdk, packages/nl2sql and packages/api are COPYed, so of the three manifests:

• packages/nl2sql/pyproject.toml declares readme = "README.md", and packages/nl2sql/README.md must survive — a missing readme fails the wheel build. It is not excluded, and the built image's nl2sql-engine metadata carries Description-Content-Type: text/markdown with the README body, which proves it was picked up.
• packages/adapter-sdk/pyproject.toml declares no readme and the package has no README.md.
• packages/api/pyproject.toml declares no readme (it has a README.md, but nothing references it).

Patterns are matched against the path relative to the context root, so repo-level directories are named directly and anything that also appears inside a package (build, dist, *.egg-info, __pycache__, .pytest_cache) is prefixed with **/. data/ is excluded safely — the demo stack bind-mounts it at run time, it is never copied at build time.

Local build evidence

CI cannot verify this: no workflow builds the image on a PR. The verification is a local build from a clean context.

docker build -f packages/api/Dockerfile -t nl2sql-api:test .

• Result: succeeds (BUILD_EXIT=0). Same command failed with the "not found" error before, using the old context.
• Context transferred:890.43 kB (plus a 1.06 kB .dockerignore), down from a 993 MB working tree.
• Final image size: 1.67 GB.
• Installed from local sources, not PyPI — the build log shows Processing ./packages/adapter-sdk, Processing ./packages/nl2sql, Processing ./packages/api, then Building wheel for nl2sql-adapter-sdk / nl2sql-engine / nl2sql-api (pyproject.toml). There is no Downloading nl2sql... line anywhere.

$ docker run --rm nl2sql-api:test python -c "import nl2sql, nl2sql_api; print('ok')"
ok
$ docker run --rm nl2sql-api:test pip show nl2sql-engine | head -3
Name: nl2sql-engine
Version: 0.1.0
Summary: Natural-language-to-SQL engine, CLI and database adapters

nl2sql-api and nl2sql-adapter-sdk are also 0.1.0. The [postgres,mysql] extras resolved (import psycopg2, pymysql succeeds) and nl2sql --help runs. Starting the container reaches uvicorn and application startup, then stops at datasource configuration, which is expected — the image needs configs/ and live databases mounted at run time, exactly as the demo stack provides.

Nothing was pushed, dispatched, re-run or tagged.

Docs

• docs/development/releasing.md — the ghcr step described the Dockerfile as installing from PyPI. Corrected, with the context requirement and the reason needs: pypi stays.
• docs/getting_started/docker.md — already told readers to build from the repo root; it now says why, and describes the new .dockerignore.
• docs/deployment/docker.md needed no change: it covers deploying the service, not building the image.

mkdocs build --strict is clean, from a throwaway venv built from requirements-docs.txt.

Baselines

Unchanged: unit 231 passed, 1 skipped, 47 deselected; key-free integration 28 passed.

Out of scope, reported not fixed

packages/api/Dockerfile.dev is genuinely broken and is not touched here. Ten of its twenty COPY lines reference paths deleted in the Task 10 packaging collapse — packages/core, packages/adapter-sqlalchemy and packages/adapters/{mssql,mysql,postgres,sqlite} — and a build fails the same way this bug did:

ERROR: failed to solve: failed to compute cache key: ... "/packages/adapters/sqlite/src": not found

Nothing references it: no workflow, no compose file, no doc, and no code path. It should be deleted, but that is a separate decision and a separate PR.

[nadeem4]

The failure

The ghcr job was the only leg of run 33198050069 to fail on the v0.1.0 release. All three packages reached PyPI, the tag, the GitHub Release and the versioned docs all succeeded; only the image build did not:

"/packages/adapter-sdk": not found
"/packages/api": not found
"/packages/nl2sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key

Cause: the build context does not match the Dockerfile's COPY paths

packages/api/Dockerfile installs the three packages from their local sources and writes its COPY paths relative to the repository root:

COPY ./packages/adapter-sdk /app/packages/adapter-sdk
COPY ./packages/nl2sql /app/packages/nl2sql
COPY ./packages/api /app/packages/api

COPY resolves against the build context, and the workflow set context: packages/api. So buildx looked for packages/api/packages/adapter-sdk, which does not exist — hence "not found" for all three.

The Dockerfile was changed in Task 13 to install from local paths (nothing was on PyPI yet); the workflow's context was never updated to match. The demo stack has had this right all along — packages/nl2sql/src/nl2sql/cli/demo/schemas.py generates context: .. with dockerfile: packages/api/Dockerfile. The workflow was the outlier.

The fix points the context at the repository root and names the Dockerfile explicitly (both are documented inputs of docker/build-push-action@v6):

context: .file: packages/api/Dockerfile

The stale comment above the job — which claimed the Dockerfile installs from PyPI — is corrected. needs: pypi is kept deliberately, but for a different reason than before: the image build no longer depends on PyPI, so the dependency now only ensures the image is published for a release that actually reached PyPI.

The .dockerignore is new, and why

There was no .dockerignore at the repo root or in packages/api. With context: ., the entire working tree is sent to the daemon. On CI the checkout is clean so it would have worked, but it is wasteful there and slow-to-broken on a developer machine, where the tree includes .venv-dev/ (857 MB), chroma_db/ (94 MB), site/, data/, logs/, .git/, __pycache__/ and stale build/, dist/ and *.egg-info directories — 993 MB in total on this checkout.

The ignore list was chosen against what the build actually needs. Only packages/adapter-sdk, packages/nl2sql and packages/api are COPYed, so of the three manifests:

• packages/nl2sql/pyproject.toml declares readme = "README.md", and packages/nl2sql/README.md must survive — a missing readme fails the wheel build. It is not excluded, and the built image's nl2sql-engine metadata carries Description-Content-Type: text/markdown with the README body, which proves it was picked up.
• packages/adapter-sdk/pyproject.toml declares no readme and the package has no README.md.
• packages/api/pyproject.toml declares no readme (it has a README.md, but nothing references it).

Patterns are matched against the path relative to the context root, so repo-level directories are named directly and anything that also appears inside a package (build, dist, *.egg-info, __pycache__, .pytest_cache) is prefixed with **/. data/ is excluded safely — the demo stack bind-mounts it at run time, it is never copied at build time.

Local build evidence

CI cannot verify this: no workflow builds the image on a PR. The verification is a local build from a clean context.

docker build -f packages/api/Dockerfile -t nl2sql-api:test .

• Result: succeeds (BUILD_EXIT=0). Same command failed with the "not found" error before, using the old context.
• Context transferred:890.43 kB (plus a 1.06 kB .dockerignore), down from a 993 MB working tree.
• Final image size: 1.67 GB.
• Installed from local sources, not PyPI — the build log shows Processing ./packages/adapter-sdk, Processing ./packages/nl2sql, Processing ./packages/api, then Building wheel for nl2sql-adapter-sdk / nl2sql-engine / nl2sql-api (pyproject.toml). There is no Downloading nl2sql... line anywhere.

$ docker run --rm nl2sql-api:test python -c "import nl2sql, nl2sql_api; print('ok')"
ok
$ docker run --rm nl2sql-api:test pip show nl2sql-engine | head -3
Name: nl2sql-engine
Version: 0.1.0
Summary: Natural-language-to-SQL engine, CLI and database adapters

nl2sql-api and nl2sql-adapter-sdk are also 0.1.0. The [postgres,mysql] extras resolved (import psycopg2, pymysql succeeds) and nl2sql --help runs. Starting the container reaches uvicorn and application startup, then stops at datasource configuration, which is expected — the image needs configs/ and live databases mounted at run time, exactly as the demo stack provides.

Nothing was pushed, dispatched, re-run or tagged.

Docs

• docs/development/releasing.md — the ghcr step described the Dockerfile as installing from PyPI. Corrected, with the context requirement and the reason needs: pypi stays.
• docs/getting_started/docker.md — already told readers to build from the repo root; it now says why, and describes the new .dockerignore.
• docs/deployment/docker.md needed no change: it covers deploying the service, not building the image.

mkdocs build --strict is clean, from a throwaway venv built from requirements-docs.txt.

Baselines

Unchanged: unit 231 passed, 1 skipped, 47 deselected; key-free integration 28 passed.

Out of scope, reported not fixed

packages/api/Dockerfile.dev is genuinely broken and is not touched here. Ten of its twenty COPY lines reference paths deleted in the Task 10 packaging collapse — packages/core, packages/adapter-sqlalchemy and packages/adapters/{mssql,mysql,postgres,sqlite} — and a build fails the same way this bug did:

ERROR: failed to solve: failed to compute cache key: ... "/packages/adapters/sqlite/src": not found

Nothing references it: no workflow, no compose file, no doc, and no code path. It should be deleted, but that is a separate decision and a separate PR.

[nadeem4]

The failure

The ghcr job was the only leg of run 33198050069 to fail on the v0.1.0 release. All three packages reached PyPI, the tag, the GitHub Release and the versioned docs all succeeded; only the image build did not:

"/packages/adapter-sdk": not found
"/packages/api": not found
"/packages/nl2sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key

Cause: the build context does not match the Dockerfile's COPY paths

packages/api/Dockerfile installs the three packages from their local sources and writes its COPY paths relative to the repository root:

COPY ./packages/adapter-sdk /app/packages/adapter-sdk
COPY ./packages/nl2sql /app/packages/nl2sql
COPY ./packages/api /app/packages/api

COPY resolves against the build context, and the workflow set context: packages/api. So buildx looked for packages/api/packages/adapter-sdk, which does not exist — hence "not found" for all three.

The Dockerfile was changed in Task 13 to install from local paths (nothing was on PyPI yet); the workflow's context was never updated to match. The demo stack has had this right all along — packages/nl2sql/src/nl2sql/cli/demo/schemas.py generates context: .. with dockerfile: packages/api/Dockerfile. The workflow was the outlier.

The fix points the context at the repository root and names the Dockerfile explicitly (both are documented inputs of docker/build-push-action@v6):

context: .file: packages/api/Dockerfile

The stale comment above the job — which claimed the Dockerfile installs from PyPI — is corrected. needs: pypi is kept deliberately, but for a different reason than before: the image build no longer depends on PyPI, so the dependency now only ensures the image is published for a release that actually reached PyPI.

The .dockerignore is new, and why

There was no .dockerignore at the repo root or in packages/api. With context: ., the entire working tree is sent to the daemon. On CI the checkout is clean so it would have worked, but it is wasteful there and slow-to-broken on a developer machine, where the tree includes .venv-dev/ (857 MB), chroma_db/ (94 MB), site/, data/, logs/, .git/, __pycache__/ and stale build/, dist/ and *.egg-info directories — 993 MB in total on this checkout.

The ignore list was chosen against what the build actually needs. Only packages/adapter-sdk, packages/nl2sql and packages/api are COPYed, so of the three manifests:

• packages/nl2sql/pyproject.toml declares readme = "README.md", and packages/nl2sql/README.md must survive — a missing readme fails the wheel build. It is not excluded, and the built image's nl2sql-engine metadata carries Description-Content-Type: text/markdown with the README body, which proves it was picked up.
• packages/adapter-sdk/pyproject.toml declares no readme and the package has no README.md.
• packages/api/pyproject.toml declares no readme (it has a README.md, but nothing references it).

Patterns are matched against the path relative to the context root, so repo-level directories are named directly and anything that also appears inside a package (build, dist, *.egg-info, __pycache__, .pytest_cache) is prefixed with **/. data/ is excluded safely — the demo stack bind-mounts it at run time, it is never copied at build time.

Local build evidence

CI cannot verify this: no workflow builds the image on a PR. The verification is a local build from a clean context.

docker build -f packages/api/Dockerfile -t nl2sql-api:test .

• Result: succeeds (BUILD_EXIT=0). Same command failed with the "not found" error before, using the old context.
• Context transferred:890.43 kB (plus a 1.06 kB .dockerignore), down from a 993 MB working tree.
• Final image size: 1.67 GB.
• Installed from local sources, not PyPI — the build log shows Processing ./packages/adapter-sdk, Processing ./packages/nl2sql, Processing ./packages/api, then Building wheel for nl2sql-adapter-sdk / nl2sql-engine / nl2sql-api (pyproject.toml). There is no Downloading nl2sql... line anywhere.

$ docker run --rm nl2sql-api:test python -c "import nl2sql, nl2sql_api; print('ok')"
ok
$ docker run --rm nl2sql-api:test pip show nl2sql-engine | head -3
Name: nl2sql-engine
Version: 0.1.0
Summary: Natural-language-to-SQL engine, CLI and database adapters

nl2sql-api and nl2sql-adapter-sdk are also 0.1.0. The [postgres,mysql] extras resolved (import psycopg2, pymysql succeeds) and nl2sql --help runs. Starting the container reaches uvicorn and application startup, then stops at datasource configuration, which is expected — the image needs configs/ and live databases mounted at run time, exactly as the demo stack provides.

Nothing was pushed, dispatched, re-run or tagged.

Docs

• docs/development/releasing.md — the ghcr step described the Dockerfile as installing from PyPI. Corrected, with the context requirement and the reason needs: pypi stays.
• docs/getting_started/docker.md — already told readers to build from the repo root; it now says why, and describes the new .dockerignore.
• docs/deployment/docker.md needed no change: it covers deploying the service, not building the image.

mkdocs build --strict is clean, from a throwaway venv built from requirements-docs.txt.

Baselines

Unchanged: unit 231 passed, 1 skipped, 47 deselected; key-free integration 28 passed.

Out of scope, reported not fixed

packages/api/Dockerfile.dev is genuinely broken and is not touched here. Ten of its twenty COPY lines reference paths deleted in the Task 10 packaging collapse — packages/core, packages/adapter-sqlalchemy and packages/adapters/{mssql,mysql,postgres,sqlite} — and a build fails the same way this bug did:

ERROR: failed to solve: failed to compute cache key: ... "/packages/adapters/sqlite/src": not found

Nothing references it: no workflow, no compose file, no doc, and no code path. It should be deleted, but that is a separate decision and a separate PR.

[nadeem4]

The failure

The ghcr job was the only leg of run 33198050069 to fail on the v0.1.0 release. All three packages reached PyPI, the tag, the GitHub Release and the versioned docs all succeeded; only the image build did not:

"/packages/adapter-sdk": not found
"/packages/api": not found
"/packages/nl2sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key

Cause: the build context does not match the Dockerfile's COPY paths

packages/api/Dockerfile installs the three packages from their local sources and writes its COPY paths relative to the repository root:

COPY ./packages/adapter-sdk /app/packages/adapter-sdk
COPY ./packages/nl2sql /app/packages/nl2sql
COPY ./packages/api /app/packages/api

COPY resolves against the build context, and the workflow set context: packages/api. So buildx looked for packages/api/packages/adapter-sdk, which does not exist — hence "not found" for all three.

The Dockerfile was changed in Task 13 to install from local paths (nothing was on PyPI yet); the workflow's context was never updated to match. The demo stack has had this right all along — packages/nl2sql/src/nl2sql/cli/demo/schemas.py generates context: .. with dockerfile: packages/api/Dockerfile. The workflow was the outlier.

The fix points the context at the repository root and names the Dockerfile explicitly (both are documented inputs of docker/build-push-action@v6):

context: .file: packages/api/Dockerfile

The stale comment above the job — which claimed the Dockerfile installs from PyPI — is corrected. needs: pypi is kept deliberately, but for a different reason than before: the image build no longer depends on PyPI, so the dependency now only ensures the image is published for a release that actually reached PyPI.

The .dockerignore is new, and why

There was no .dockerignore at the repo root or in packages/api. With context: ., the entire working tree is sent to the daemon. On CI the checkout is clean so it would have worked, but it is wasteful there and slow-to-broken on a developer machine, where the tree includes .venv-dev/ (857 MB), chroma_db/ (94 MB), site/, data/, logs/, .git/, __pycache__/ and stale build/, dist/ and *.egg-info directories — 993 MB in total on this checkout.

The ignore list was chosen against what the build actually needs. Only packages/adapter-sdk, packages/nl2sql and packages/api are COPYed, so of the three manifests:

• packages/nl2sql/pyproject.toml declares readme = "README.md", and packages/nl2sql/README.md must survive — a missing readme fails the wheel build. It is not excluded, and the built image's nl2sql-engine metadata carries Description-Content-Type: text/markdown with the README body, which proves it was picked up.
• packages/adapter-sdk/pyproject.toml declares no readme and the package has no README.md.
• packages/api/pyproject.toml declares no readme (it has a README.md, but nothing references it).

Patterns are matched against the path relative to the context root, so repo-level directories are named directly and anything that also appears inside a package (build, dist, *.egg-info, __pycache__, .pytest_cache) is prefixed with **/. data/ is excluded safely — the demo stack bind-mounts it at run time, it is never copied at build time.

Local build evidence

CI cannot verify this: no workflow builds the image on a PR. The verification is a local build from a clean context.

docker build -f packages/api/Dockerfile -t nl2sql-api:test .

• Result: succeeds (BUILD_EXIT=0). Same command failed with the "not found" error before, using the old context.
• Context transferred:890.43 kB (plus a 1.06 kB .dockerignore), down from a 993 MB working tree.
• Final image size: 1.67 GB.
• Installed from local sources, not PyPI — the build log shows Processing ./packages/adapter-sdk, Processing ./packages/nl2sql, Processing ./packages/api, then Building wheel for nl2sql-adapter-sdk / nl2sql-engine / nl2sql-api (pyproject.toml). There is no Downloading nl2sql... line anywhere.

$ docker run --rm nl2sql-api:test python -c "import nl2sql, nl2sql_api; print('ok')"
ok
$ docker run --rm nl2sql-api:test pip show nl2sql-engine | head -3
Name: nl2sql-engine
Version: 0.1.0
Summary: Natural-language-to-SQL engine, CLI and database adapters

nl2sql-api and nl2sql-adapter-sdk are also 0.1.0. The [postgres,mysql] extras resolved (import psycopg2, pymysql succeeds) and nl2sql --help runs. Starting the container reaches uvicorn and application startup, then stops at datasource configuration, which is expected — the image needs configs/ and live databases mounted at run time, exactly as the demo stack provides.

Nothing was pushed, dispatched, re-run or tagged.

Docs

• docs/development/releasing.md — the ghcr step described the Dockerfile as installing from PyPI. Corrected, with the context requirement and the reason needs: pypi stays.
• docs/getting_started/docker.md — already told readers to build from the repo root; it now says why, and describes the new .dockerignore.
• docs/deployment/docker.md needed no change: it covers deploying the service, not building the image.

mkdocs build --strict is clean, from a throwaway venv built from requirements-docs.txt.

Baselines

Unchanged: unit 231 passed, 1 skipped, 47 deselected; key-free integration 28 passed.

Out of scope, reported not fixed

packages/api/Dockerfile.dev is genuinely broken and is not touched here. Ten of its twenty COPY lines reference paths deleted in the Task 10 packaging collapse — packages/core, packages/adapter-sqlalchemy and packages/adapters/{mssql,mysql,postgres,sqlite} — and a build fails the same way this bug did:

ERROR: failed to solve: failed to compute cache key: ... "/packages/adapters/sqlite/src": not found

Nothing references it: no workflow, no compose file, no doc, and no code path. It should be deleted, but that is a separate decision and a separate PR.

[nadeem4]

The failure

The ghcr job was the only leg of run 33198050069 to fail on the v0.1.0 release. All three packages reached PyPI, the tag, the GitHub Release and the versioned docs all succeeded; only the image build did not:

"/packages/adapter-sdk": not found
"/packages/api": not found
"/packages/nl2sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key

Cause: the build context does not match the Dockerfile's COPY paths

packages/api/Dockerfile installs the three packages from their local sources and writes its COPY paths relative to the repository root:

COPY ./packages/adapter-sdk /app/packages/adapter-sdk
COPY ./packages/nl2sql /app/packages/nl2sql
COPY ./packages/api /app/packages/api

COPY resolves against the build context, and the workflow set context: packages/api. So buildx looked for packages/api/packages/adapter-sdk, which does not exist — hence "not found" for all three.

The Dockerfile was changed in Task 13 to install from local paths (nothing was on PyPI yet); the workflow's context was never updated to match. The demo stack has had this right all along — packages/nl2sql/src/nl2sql/cli/demo/schemas.py generates context: .. with dockerfile: packages/api/Dockerfile. The workflow was the outlier.

The fix points the context at the repository root and names the Dockerfile explicitly (both are documented inputs of docker/build-push-action@v6):

context: .file: packages/api/Dockerfile

The stale comment above the job — which claimed the Dockerfile installs from PyPI — is corrected. needs: pypi is kept deliberately, but for a different reason than before: the image build no longer depends on PyPI, so the dependency now only ensures the image is published for a release that actually reached PyPI.

The .dockerignore is new, and why

There was no .dockerignore at the repo root or in packages/api. With context: ., the entire working tree is sent to the daemon. On CI the checkout is clean so it would have worked, but it is wasteful there and slow-to-broken on a developer machine, where the tree includes .venv-dev/ (857 MB), chroma_db/ (94 MB), site/, data/, logs/, .git/, __pycache__/ and stale build/, dist/ and *.egg-info directories — 993 MB in total on this checkout.

The ignore list was chosen against what the build actually needs. Only packages/adapter-sdk, packages/nl2sql and packages/api are COPYed, so of the three manifests:

• packages/nl2sql/pyproject.toml declares readme = "README.md", and packages/nl2sql/README.md must survive — a missing readme fails the wheel build. It is not excluded, and the built image's nl2sql-engine metadata carries Description-Content-Type: text/markdown with the README body, which proves it was picked up.
• packages/adapter-sdk/pyproject.toml declares no readme and the package has no README.md.
• packages/api/pyproject.toml declares no readme (it has a README.md, but nothing references it).

Patterns are matched against the path relative to the context root, so repo-level directories are named directly and anything that also appears inside a package (build, dist, *.egg-info, __pycache__, .pytest_cache) is prefixed with **/. data/ is excluded safely — the demo stack bind-mounts it at run time, it is never copied at build time.

Local build evidence

CI cannot verify this: no workflow builds the image on a PR. The verification is a local build from a clean context.

docker build -f packages/api/Dockerfile -t nl2sql-api:test .

• Result: succeeds (BUILD_EXIT=0). Same command failed with the "not found" error before, using the old context.
• Context transferred:890.43 kB (plus a 1.06 kB .dockerignore), down from a 993 MB working tree.
• Final image size: 1.67 GB.
• Installed from local sources, not PyPI — the build log shows Processing ./packages/adapter-sdk, Processing ./packages/nl2sql, Processing ./packages/api, then Building wheel for nl2sql-adapter-sdk / nl2sql-engine / nl2sql-api (pyproject.toml). There is no Downloading nl2sql... line anywhere.

$ docker run --rm nl2sql-api:test python -c "import nl2sql, nl2sql_api; print('ok')"
ok
$ docker run --rm nl2sql-api:test pip show nl2sql-engine | head -3
Name: nl2sql-engine
Version: 0.1.0
Summary: Natural-language-to-SQL engine, CLI and database adapters

nl2sql-api and nl2sql-adapter-sdk are also 0.1.0. The [postgres,mysql] extras resolved (import psycopg2, pymysql succeeds) and nl2sql --help runs. Starting the container reaches uvicorn and application startup, then stops at datasource configuration, which is expected — the image needs configs/ and live databases mounted at run time, exactly as the demo stack provides.

Nothing was pushed, dispatched, re-run or tagged.

Docs

• docs/development/releasing.md — the ghcr step described the Dockerfile as installing from PyPI. Corrected, with the context requirement and the reason needs: pypi stays.
• docs/getting_started/docker.md — already told readers to build from the repo root; it now says why, and describes the new .dockerignore.
• docs/deployment/docker.md needed no change: it covers deploying the service, not building the image.

mkdocs build --strict is clean, from a throwaway venv built from requirements-docs.txt.

Baselines

Unchanged: unit 231 passed, 1 skipped, 47 deselected; key-free integration 28 passed.

Out of scope, reported not fixed

packages/api/Dockerfile.dev is genuinely broken and is not touched here. Ten of its twenty COPY lines reference paths deleted in the Task 10 packaging collapse — packages/core, packages/adapter-sqlalchemy and packages/adapters/{mssql,mysql,postgres,sqlite} — and a build fails the same way this bug did:

ERROR: failed to solve: failed to compute cache key: ... "/packages/adapters/sqlite/src": not found

Nothing references it: no workflow, no compose file, no doc, and no code path. It should be deleted, but that is a separate decision and a separate PR.