watermelonwolverine / fvttoptimizer

Optimizes image files by converting them to webp while also updating all references.
MIT License
20 stars 1 forks source link

Trying to create a Docker image - Keep getting 'image.jpg is not in the configured foundry Data folder.' #6

Closed gCardinal closed 2 years ago

gCardinal commented 2 years ago

As the title say, I'm trying to get this tool to work in a Docker container, but I'm having an issue that I can't figure out...

I'm building the image like so:

FROM python:3.10.0

ARG FVTT_OPTIMIZER_VERSION=0.1.3

RUN curl -L https://github.com/watermelonwolverine/fvttoptimizer/releases/download/$FVTT_OPTIMIZER_VERSION/fvttoptimizer --output usr/bin/fvttoptimizer
RUN chmod +x usr/bin/fvttoptimizer
RUN echo '{"absolute_path_to_foundry_data":"/app/Data"}' > /etc/fvttoptimizer.conf

CMD ["fvttoptimizer"]

Which I then configure with docker-compose:

version: "3.7"

services:
    fvttoptimizer:
        build: python
        volumes:
            - ${FOUNDRY_DATA_VOLUME}:/app

# FOUNDRY_DATA_VOLUME is the directory that contains `Config`, `Data` and `Logs`

However, when ran (docker-compose run --rm fvttoptimizer fvttoptimizer --verbose-debug ./Barney.jpg) I get the error in the title. Running docker-compose run --rm fvttoptimizer ls -la /app/Data, I can confirm the image exists.

The debug output looks like this:

root - DEBUG - Got arguments ['fvttoptimizer', '--verbose-debug', '--recursive', './Barney.jpg']
root - DEBUG - Reading config from: /etc/fvttoptimizer.conf
root - DEBUG - Running with target_path='./Barney.jpg', config='{'_RunConfig__program_config': {'_ProgramConfigImpl__abs_path_to_foundry_data': '/app/Data'}, 'skip_existing': False, 'skip_webp': False, 'recursive': True, 'quality': 75, 'override_percent': 25}'
root - ERROR - /Barney.jpg is not in the configured foundry Data folder.
/Barney.jpg is not in the configured foundry Data folder.

I pushed a branch on my repo where it should be possible to reproduce the issue, or at the very least look at my configuration: https://github.com/gCardinal/foundrty-vtt/blob/feature/use-fvttoptimizer

watermelonwolverine commented 2 years ago

I haven't worked extensively with docker, but I did a quick test:

Dockerfile:

FROM ubuntu:18.04

docker-compose.yml

version: "3.3"

services:
    docker-test:
        build: .
        volumes:
            - /home/user/docker-test

running:

docker-compose run --rm docker-test ls .

gives me:

bin   dev  home  lib64  mnt  proc  run   srv  tmp  var
boot  etc  lib   media  opt  root  sbin  sys  usr

no matter from where I execute it. ==> Relative paths are interpreted inside the docker service, meaning they are relative to the service's working directory, not to the current working directory.

You got a few options, I guess the easiest one would be to do something like this:

docker-compose run --rm fvttoptimizer fvttoptimizer | realpath ./Barney.jpg
gCardinal commented 2 years ago

Relative paths are interpreted inside the docker service, meaning they are relative to the service's working directory, not to the current working directory.

Yeah, but with the config I had I was sure the relative image path I was giving pointed to a file in the Data directory. Your reply did point me in the right direction though and it was definitely on me. The solution was:

version: "3.7"

services:
    fvttoptimizer:
        build: python
        volumes:
            - ${FOUNDRY_DATA_VOLUME}:/app
        working_dir: /app/Data

Then I tried to pass a glob pattern and it didn't work, neither did passing multiple images, so I build a small utility script to serve as my container's entrypoint.

Is glob support something you would be open to supporting?

watermelonwolverine commented 2 years ago

You gave it ./Barney.jpg which was interpreted as /Barney.jpg (which is not in the data dir) because the service's working directory was / even though the directory you called it from may have been /app/Data. I think setting the working_dir to /app/Data doesn't completely solve the issue. It allows you to use relative paths in /app/Data but you still can't use relative paths from anywhere else. So I guess the usefulness depends on the complexity of your directory tree. Nevertheless I think this issue can be closed as it is purely docker specific. Wildcard/Glob support will come some day when I come around to implement it.