error building sdx controller docker image

[lmarinve]

I am running docker build --no-cache -f ./Dockerfile -t sdx-controller .

and I getting this error

=> ERROR [stage-0 6/6] RUN --mount=source=.git,target=.git,type=bind pip install --no-cache-dir .[wsgi] 6.6s

---

[stage-0 6/6] RUN --mount=source=.git,target=.git,type=bind pip install --no-cache-dir .[wsgi]:
2.444 Processing /usr/src/app
2.450 Installing build dependencies: started
5.803 Installing build dependencies: finished with status 'done'
5.807 Getting requirements to build wheel: started
6.079 Getting requirements to build wheel: finished with status 'error' 6.092 error: subprocess-exited-with-error 6.092
6.092 × Getting requirements to build wheel did not run successfully. 6.092 │ exit code: 1 6.092 ╰─> [35 lines of output] ... 6.092 _version_missing(config) 6.092 File "/tmp/pip-build-env-q_ja4dih/overlay/lib/python3.9/site-packages/setuptools_scm/_get_version_impl.py", line 112, in _version_missing 6.092 raise LookupError( 6.092 LookupError: setuptools-scm was unable to detect version for /usr/src/app. 6.092
6.092 Make sure you're either building from a fully intact git repository or PyPI tarballs. Most other sources (such as GitHub's tarballs, a git checkout without the .git folder) don't contain the necessary metadata and will not work. 6.092
6.092 For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj 6.092 [end of output] 6.092
6.092 note: This error originates from a subprocess, and is likely not a problem with pip. 6.096 error: subprocess-exited-with-error 6.096 6.096 × Getting requirements to build wheel did not run successfully. 6.096 │ exit code: 1 6.096 ╰─> See above for output. 6.096 6.096 note: This error originates from a subprocess, and is likely not a problem with pip. 6.321 6.321 [notice] A new release of pip is available: 23.0.1 -> 24.0 6.321 [notice] To update, run: pip install --upgrade pip

Dockerfile:18

17 | # https://github.com/pypa/setuptools_scm/issues/77#issuecomment-844927695 18 | >>> RUN --mount=source=.git,target=.git,type=bind \ 19 | >>> pip install --no-cache-dir .[wsgi] 20 |

ERROR: failed to solve: process "/bin/sh -c pip install --no-cache-dir .[wsgi]" did not complete successfully: exit code: 1

[italovalcy]

@lmarinve this is because when you have a gitsubmodule the .git folder actually becomes just a clear text to the original folder dir (under the parent directory). Addiitionally, the .git directory is being used as part of docker build process for sdx-controller to overcome an issue with setuptools_scm (see https://github.com/atlanticwave-sdx/sdx-controller/blob/main/Dockerfile#L15-L19)

[lmarinve]

What is the purpose of this command? Can I comment on it?

RUN --mount=source=.git,target=.git,type=bind \

pip install --no-cache-dir .[wsgi]

[sajith]

@lmarinve The purpose of those lines is in the comment right above it, and docker build will break if you simply comment those lines out:

https://github.com/atlanticwave-sdx/sdx-controller/blob/23d4f8c2aa731659259b0b85fa0e1c1e5e14d38b/Dockerfile#L15-L17

This requires a relatively newer docker version with BuildKit support. Using setuptools_scm will help us to get the version of sdx-controller programmatically (git commit hash included), and eventually add a /version API (issue #219).

In any case, I don't think you should be building sdx-controller docker images separately. That is duplicate effort, and you are likely to end up with a bunch of local changes in order to make things "work". Instead, it would be much more helpful if you can use the images from Docker Hub (see https://hub.docker.com/r/awsdx/sdx-controller -- they are tagged with commit hashes or release tags, so you don't have to necessarily use the latest image always, although that would be useful), and let the problems surface, and report the problems in the appropriate repository when it is appropriate. Letting problems surface is the main point (or the whole point?) of continuous integration, as far as I understand.

Being able to build docker images off a git submodule is not a use case I am able to support.

[YufengXin]

Completed discussion