Building Docker fails to chmod it .sh files

[joan38]

I have a script in src/docker/opt/docker/bin/launch.sh.

The generated Dockerfile:

RUN ["chmod", "-R", "u=rX,g=rX", "/opt/docker"]
RUN ["chmod", "u+x,g+x", "/opt/docker/bin/server"]
RUN ["chmod", "u+x,g+x", "opt/docker/bin/launch.sh"]

See the missing / in front of opt that leads to the following error when Docker/publishLocal:

chmod: cannot access 'opt/docker/bin/launch.sh': No such file or directory

Workaround:

inConfig(Docker)(
  dockerPackageMappings := MappingsHelper
    .contentOf(sourceDirectory.value)
    .map { case (from, to) => from -> Paths.get("/", to).toString }
)

Thanks

[muuki88]

Thanks for your bug request 😃

A small build.sbt to reproduce this error would be nice. Also information about the system you are building the docker image.

[adarshaj]

I am facing the exact same issue, we use an entrypoint.sh in src/docker/opt/bin/docker and the leading / at the beginning is missing (and since work dir is /opt/docker the relative path does not match).

[adarshaj]

@muuki88 - I've created a repro here: https://github.com/hackcave/sbt-native-packager-docker-issue-1304 , sbt docker:publishLocal should give you the error. we can see the file exists at /opt/bin/docker/entrypoint.sh within the docker image, but the generated chmod command fails to add / prefix.

[muuki88]

Thanks a lot for putting together a reproducible test case.

To he honest I don't know if I have the time to work on this, but if you would like to do I'll give you all necessary guidance you need 😊

[adarshaj]

@muuki88 - I thought about the issue deeper. I think once we set the workdir (the defaultLinuxInstallation value), we should only rely on relative paths from that point onwards. In a multistage build, we are anyway copying only files under this workdir, so even if the user had copied some files in stage0, they will not end up in mainstage. The current COPY generates an absolute path for destination, can we instead make it relative? What do you think of this?

[adarshaj]

we can see the file exists at /opt/bin/docker/entrypoint.sh within the docker image

Oops, I switched directories in my reproduction, I was actually wanting to put entrypoint.sh in /opt/docker/bin but I swapped bin and docker by mistake.

[adarshaj]

Okay, now I understand the core of problem:
This issue will occur only when the folder inside src/docker is named opt. This won't affect otherwise, this could be easily solved if we copy the files in src/docker in a place that's isolated from the generated scripts/jar files? (btw, is the current behavior intended? As in, let the user create files in opt, such that it can potentially change generated scripts/jars?)

[muuki88]

Sorry for the late reply.

This issue will occur only when the folder inside src/docker is named opt

That's an unexpected behaviour. If you put a folder have a folder src/docker/opt/ then it should appear in /opt/opt and not disappear.

It should work if you put the files in src/docker/bin and then they will appear in /opt/docker/bin. At least that what I would expect. The defaultLinuxInstallation is prepended to all path mappings.

btw, is the current behavior intended? As in, let the user create files in opt, such that it can potentially change generated scripts/jars?

Yeah. There are plenty of ways to change the generated bash/bat scripts. See https://sbt-native-packager.readthedocs.io/en/stable/archetypes/java_app/customize.html#start-script-customizations