sqitchers / docker-sqitch

Docker Image packaging for Sqitch
MIT License
35 stars 39 forks source link

Cannot use sqitch.conf in parent directories of current working directory #48

Closed ewie closed 1 year ago

ewie commented 1 year ago

Situation

My repository contains multiple Sqitch projects: a core and multiple modules on which core depends (via sqitch-add --requires):

$ tree
.
├── core
│   ├── Makefile
│   └── sqitch.plan
├── Makefile
├── module-a
│   ├── Makefile
│   └── sqitch.plan
├── module-b
│   ├── Makefile
│   └── sqitch.plan
└── sqitch.conf

I want to use a single sqitch.conf to share configuration such as engine and targets. The modules must be separate Sqitch projects because they are just wrappers around third-party schemas in order to "sqitchify" them and depend on them from core.

Running plain sqitch from the sub directories containing the plan files works without flaws. Sqitch finds the sqitch.conf in the parent directory. A feature I read about on https://groups.google.com/g/sqitch-users/c/NGQyzN6jsG8/m/2WbfykakAwAJ

Problem

I use docker-sqitch.sh as drop-in replacement in my CI pipeline because its faster to set up than installing Sqitch from CPAN. The pipeline only runs deploy and revert for testing as well as pg_prove.

The problem is that docker-sqitch.sh mounts the current working directory and thus cannot access parent directories to find sqitch.conf. It obviously works by running docker-sqitch.sh -C core from the repository root. But I rely on make to run tests locally as well as in the pipeline, i.e. make test runs make -C core test etc.

Is my setup flawed, even though it works with plain sqitch? Or is it just a limitation of docker-sqitch.sh and I should not expect it to be a drop-in replacement?

theory commented 1 year ago

Yeah, this is a limitation of using Docker: if you have a path on your host, say /home/ewie/dev/prd/mydb, and you run the script in that directory, it and its subdirectories are available in the container. However, by design it cannot go above that directory — it would be security issue if it did!

Might make sense in your case to configure your Pipeline to mount and run from the root directory of your project and either cd into the directory to run Sqitch, or maybe try sqitch --top-dir mydb.

ewie commented 1 year ago

Thanks David!

Yeah, this is a limitation of using Docker: if you have a path on your host, say /home/ewie/dev/prd/mydb, and you run the script in that directory, it and its subdirectories are available in the container. However, by design it cannot go above that directory — it would be security issue if it did!

I'm aware of the Docker design. I was wondering if you're aware that it limits docker-sqitch compared to plain Sqitch.

Might make sense in your case to configure your Pipeline to mount and run from the root directory of your project and either cd into the directory to run Sqitch, or maybe try sqitch --top-dir mydb.

I think you mean sqitch -C mydb and not sqitch --top-dir mydb (unknown option --top-dir).

That's what I'm doing right now using cd ..; sqitch -C core in core/Makefile. But maybe the use of recursive make is not ideal in the first place (https://accu.org/journals/overload/14/71/miller_2004/). A single Makefile and sqitch -C in the repository root solves the issue with the current working directory mounted in the Sqitch container.