Hey, thanks for the proposals.

Problems with bash scripts are that they also need to be tested and - if publicly delivered - written in an OS-independent manner (there are sometimes subtle differences between Linux and Darwin bash and zsh and ...). That's why we prefer to use and document the usage of standard docker compose commands instead of custom scripts (it also allows users to better understand what they're actually executing). We made an exception by introducing run-microcks.sh in the Podman installation because that couldn't be avoided at a time when launching Podman was a mess on MacOS - that said, given yesterday's test this can certainly be removed in the future.

As a consequence, I would prefer to keep the install-docker-compose.sh script "private" (not really "private" as we're working in open 😉 ) or scoped to the tests or testsuite purpose only. That way it will be easier to maintain it on our target platform only (the GitHub runners we will select to run the CI). It could serve also as an inspiration to people who would like to automate stuff but it offloads us from the burden of making something industrial.

+1 for renaming the addons file for better consistency! We'll synchronize the documentation upgrade too.

So to sum up, I think the next step is to decide the folder where to put the scripts, configurations and functional tests you're describing. I see two obvious options at the moment:

• /tests - basic but can bring confusion with unit tests we store in /src/test
• /testsuite- IMHO sounds more elaborate and different from unit tests

Personally, my preference goes to /testsuite.

Any other suggestion is welcomed!

With this, the script now handles installation for both docker as well as podman compose.

Im not sure why there are merge-conflicts. I have already rebased my branch onto origin/1.11.x? My local working tree is also clean.

cc @lbroudoux

Looks like the rebase to 1.12.x involved some conflicts. Can you fix them so that I can merge the results?