Fossil Forum

Docker parse error at Dockerfile line 44
Login

Docker parse error at Dockerfile line 44

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

Already done.