Docker parse error at Dockerfile line 44
(1) By anonymous on 2023-01-16 20:03:35 [link] [source]
Hello.
After downloading the Dockerfile from the latest version of trunk, My docker will not start the build process to create the fossil image. There is a section that was added in check-in artifact add4fb55fcbeb5cd relating to a dummy OS file. When I begin the build process with
sudo docker build -t fossil-20230116-1417:cdd89e2dbe65908c .
Docker reports
Sending build context to Docker daemon 43.52kB
Error response from daemon: dockerfile parse error line 44: unknown instruction: NAME="FOSSIL
Currently running docker on Ubuntu 22.04
Client: Docker Engine - Community
Version: 20.10.22
API version: 1.41
Go version: go1.18.9
Git commit: 3a2c30b
Built: Thu Dec 15 22:28:04 2022
OS/Arch: linux/amd64
Context: default
Experimental: true
Server: Docker Engine - Community
Engine:
Version: 20.10.22
API version: 1.41 (minimum version 1.12)
Go version: go1.18.9
Git commit: 42c8b31
Built: Thu Dec 15 22:25:49 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.15
GitCommit: 5b842e528e99d4d4c1686467debf2bd4b88ecd86
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
(2) By Stephan Beal (stephan) on 2023-01-16 20:18:09 in reply to 1 [link] [source]
My docker will not start the build process to create the fossil image.
Just FYI, i can reproduce this on Mint Linux 21.1 and our resident Docker expert (Warren) has been pinged. He'll certainly have a fix soon. (My own experimentation with a fix has failed to resolve it.)
(3) By anonymous on 2023-01-16 20:25:07 in reply to 2 [link] [source]
Roger that Stephan. I just tried rebuilding by previous Dockerfile from 2022-10-30 (I know, I should update more often ;), and it built just fine. I look forward to a solution and what it may be.
(4) By anonymous on 2023-01-17 00:50:55 in reply to 3 [link] [source]
Hi there,
See the comment in https://www.fossil-scm.org/home/artifact/cf596a996b8ee082
"here-docs" in Dockerfile are moderately new, and might need extra local config, per https://www.docker.com/blog/introduction-to-heredocs-in-dockerfiles/
You could (potentially) rewrite that fragment of the Dockerfile to use "echo" or "printf" and backslashes for continuation, if you want to test while avoiding the here-doc syntax.
Good luck with it!
(5.1) By Stephan Beal (stephan) on 2023-01-17 00:59:00 edited from 5.0 in reply to 4 [link] [source]
"here-docs" in Dockerfile are moderately new, and might need extra local config, per https://www.docker.com/blog/introduction-to-heredocs-in-dockerfiles/
@OP: given that tip, here's a workaround:
$ DOCKER_BUILDKIT=1 docker build -t fossil-test .
works for me :).
Edit: that article suggests using "buildx" instead of "build" as an alternative, but that command isn't available in the docker which comes with Mint Linux 21.1 (the latest as of this writing).
(6) By anonymous on 2023-01-17 05:16:55 in reply to 5.1 [link] [source]
Thank you very much! I read into the suggested documentation posted early about “here-docs” and as I understand it, it simply eliminates some needless escaping of new lines as well as easier docker run and copy commands/syntax. Using the ‘buildkit=1’ build option works for me as well. I started noticing a few months ago various docker projects beginning to incorporate this option in their documentation but never thought anything of it or why it was needed, just blindly followed the manual until now.
In the documentation for deploying Fossil with OCI containers ,
https://fossil-scm.org/home/doc/trunk/www/containers.md
The very first bullet point under quick start does not include this extra ‘buildkit’ option. Do you think it would be wise to update this documentation to include it, or would it be better to rewrite the Dockerfile with echo/backslashes as mentioned earlier? Other than making the file easier to write by a few characters, I’m not sure what performance implication this revised Dockerfile possesses other than the added nspawn capability that I do not use anyway.
(7.1) By Warren Young (wyoung) on 2023-01-17 05:38:55 edited from 7.0 in reply to 1 [source]
sudo docker
You shouldn't have to run docker
thru sudo
. If you do, it likely means you ignored the initial configuration advice to add your user to the docker
group, which effectively gets you root rights at build time.
As for the rest of your issue, I've reworked the way we generate /etc/os-release
in the container to avoid use of heredocs, so that it will once again build with the legacy "docker build
" mechanism, rather than require use of BuildKit, a.k.a. "docker buildx build
".
As a bonus, it will build with Podman again — or more specifically, buildah
— which currently does not support heredocs.
(8) By Gregory Boga (waterhootcork2352) on 2023-01-17 16:23:30 in reply to 7.1 [link] [source]
ignored the initial configuration advice to add your user to the docker group
I did indeed! From everything I could read, adding your own user to the docker group effectively grants that user “sudo” permissions on the host system with the added benefit (or disadvantage) of not needing a password. I was always taught to at least try to keep security high enough without friction causing people to do stupid things. Since it was optional and I don’t mind typing a password after 10 minutes, I kept the docker install as “default” as possible.
Does using sudo to run the build process otherwise affect how the fossil image is built? I’m not against creating a temporary user, adding to the docker group, building, then removing the temp user if that is the proper way / more complete way to build the image.
legacy "docker build" mechanism, rather than require use of BuildKit,
I’m not opposed to using buildkit, especially if docker eventually merges its functionality into the legacy command, much like how docker basically absorbed docker-compose into its own syntax instead of a separate program. If that is the way forward, I’m all for the future and would rather have separate documentation for Podman or updated documentation.
(9) By Warren Young (wyoung) on 2023-01-17 20:46:07 in reply to 8 [link] [source]
adding your own user to the docker group effectively grants that user “sudo” permissions on the host system
Only within the context of docker
commands, which means the only way it's equivalent to sudo
is if there's a hole in Docker Engine that allows arbitrary commands to be executed, ones not necessary to building, running, and managing containers.
Your current alternative is to run docker
through sudo
which does give you the ability to run arbitrary commands unless you've gone out of your way to add docker
to a whitelist of commands your user is allowed to run through sudo
, blocking all others. That can be done, but now what have you bought over the recommended method except a longer command?
If this concern over root privileges is a primary driving motivation for you, you should be using the Fossil in a Rootless Podman Container procedure.
There's a rootless Docker Engine method, but since I haven't tried it, it isn't documented for Fossil, seeing as how I'm the only one doing the documenting at the moment. :) There's a fair chance the Podman rootless info will help, though.
I’m not opposed to using buildkit, especially if docker eventually merges its functionality into the legacy command
Since I've not heard of any such plans, I can't plan around it myself, particularly given that your example…
like how docker basically absorbed docker-compose into its own syntax
…took years to hit GA.
rather have separate documentation for Podman