1.1.0 (and perhaps above) broke the use of Containerfiles #977
Labels
bug
Something isn't working
Comments
|
Found the issue, made a PR about it : #978 |
larsks
added a commit
to larsks/podman-compose
that referenced
this issue
Jun 26, 2024
In `normalize_service_final`, podman-compose would arbitrarily set the name of the Containerfile to "Dockerfile". This made the logic in `build_one` that looks for a number of different names a no-op (because by the time `build_one` is called, the container dictionary already had an explicit "Dockerfile"). Podman-compose should support building with a Containerfile (and should probably *prefer* that). This commit modifies `normalize_service_final` so that it no longer explicitly sets the `dockerfile` attribute. This allows the existing logic to find the correct file. Closes containers#977
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Installed podman-compose 1.1.0 (from pypi), it refused to build my image (raise OSError : Dockerfile not found in +ctx (/my/path)).
Downgraded to 1.0.6, it works like a charm.
Also, podman build works well.
To Reproduce
podman-compose.yml file including a build instruction to the current folder, with a Containerfile in it. Renaming the containerfile Dockerfile makes it work, but defeats the purpose of the generic name. Then run "podman compose up -d".
Expected behavior
Successful build.
Actual behavior
OSError: Dockerfile not found in /my/path
Output
If needed, I can edit this issue at a later point, I do not have the output right now due to the emergency of deployment. The error was occuring in site-packages/podman-compose.py somewhere in the lines 2400-2800, I can't remember. It displayed a full python stacktrace.
Additional context
Debian Linux 12, Podman 5.1.1 installed from Homebrew, podman-compose 1.1.0 installed from pypi.
The text was updated successfully, but these errors were encountered: