Fix E2E env with flashlight www-data (#343)

.github/workflows/quality-check.yml

@@ -1,7 +1,6 @@
 name: Quality Control
 
 env:
-  DOCKER_COMPOSE_VERSION: v2.27.0
   NODE_BUILDER_VERSION: "20"
 
 on:
@@ -114,15 +113,6 @@ jobs:
           path: vendor
           key: php-${{ hashFiles('composer.lock') }}
 
-      - name: Install docker compose
-        run: |
-          DOCKER_CONFIG=${DOCKER_CONFIG:-$HOME/.docker}
-          mkdir -p $DOCKER_CONFIG/cli-plugins
-          rm -f $DOCKER_CONFIG/cli-plugins/docker-compose
-          curl -SL https://github.com/docker/compose/releases/download/${{ env.DOCKER_COMPOSE_VERSION }}/docker-compose-linux-x86_64 \
-          -o $DOCKER_CONFIG/cli-plugins/docker-compose
-          chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
-
       - name: Install dependencies and setup e2e
         run: pnpm install --no-optional --force
         working-directory: e2e

e2e-env/README.md

@@ -13,32 +13,45 @@ stack consists of the following elements:
 For the CloudSync APIs mock, it is a NodeJS application simulating the CloudSync APIs. Requests made by `ps_eventbus` to CloudSync are redirected to the mock using a reverse proxy (nginx).
 When a request reaches the mock, it utilizes WebSockets to transmit the said request from `ps_eventbus` to the E2E tests, allowing validation of the information coming out of `ps_eventbus`.
 
+## Troubleshooting
+
+The end-to-end environment relies on PrestaShop Flashlight, which by default runs scripts and php with the user `www-data`. This user is mapped on the uid/gid _1000_, which might perfectly match your own Linux system user.
+
+However, if for any reason your uid is not 1000, you might disable code mentioned with this comment : `# Notice: you might enable this if your uid is not 1000, or encounter permission issues`. One thing you will loose, is the ability to hot-reload local vendors on your host to the guest docker container. Docker compose down/up will be your friend in that very case.
+
+If you are a MacOS user, mounting a docker won't cause any issue, as the process isolation is greater (and slower).
+
 ## Start the environment
 
 1. Create your own configuration from the default values:
+
 ```shell
 cp .env.dis .env
 ```
 
 2. start docker environment:
+
 ```shell
 docker compose up
 ```
 
 Or in detached mode:
+
 ```shell
 docker compose up -d
 ```
 
 Or specifically only starting PrestaShop (and its dependencies) with special commands to be sure your containers and volumes will be recreacted/renewed:
+
 ```shell
 docker compose up prestashop --force-recreate --renew-anon-volumes
 ```
 
 ## Make changes to the mock
 
-If you need to make change to the mocks, they can be built and run locally using scripts in ```package.json```.
+If you need to make change to the mocks, they can be built and run locally using scripts in `package.json`.
 Don't forget to rebuild your docker image for your changes to take effect immediately :
+
 ```shell
 docker compose build --no-cache
 ```

e2e-env/docker-compose.yml

@@ -18,8 +18,9 @@ services:
     volumes:
       - ..:/var/www/html/modules/ps_eventbus:rw
       - ./init-scripts:/tmp/init-scripts:ro
-      - /var/www/html/modules/ps_eventbus/vendor
-      - /var/www/html/modules/ps_eventbus/tools/vendor
+      # Notice: you might enable this if your uid is not 1000, or encounter permission issues
+      # - /var/www/html/modules/ps_eventbus/vendor
+      # - /var/www/html/modules/ps_eventbus/tools/vendor
     environment:
       - PS_DOMAIN=localhost:8000
       - ON_INIT_SCRIPT_FAILURE=fail

e2e-env/init-scripts/install-module.sh

@@ -12,43 +12,24 @@ error() {
   exit "${2:-1}"
 }
 
-run_user() {
-  sudo -g www-data -u www-data -- "$@"
-}
-
 ps_accounts_mock_install() {
   echo "* [ps_accounts_mock] downloading..."
   PS_ACCOUNTS_MOCK_VERSION="v7.0.2"
   echo "* [ps_accounts_mock] downloading..."
   wget -q -O /tmp/ps_accounts.zip "https://github.com/PrestaShopCorp/ps_accounts_mock/releases/download/${PS_ACCOUNTS_MOCK_VERSION}/ps_accounts_mock-${PS_ACCOUNTS_MOCK_VERSION}.zip"
   echo "* [ps_accounts_mock] unziping..."
-  run_user unzip -qq /tmp/ps_accounts.zip -d /var/www/html/modules
+  unzip -qq /tmp/ps_accounts.zip -d /var/www/html/modules
   echo "* [ps_accounts_mock] installing the module..."
   cd "$PS_FOLDER"
-  run_user php -d memory_limit=-1 bin/console prestashop:module --no-interaction install "ps_accounts"
+  php -d memory_limit=-1 bin/console prestashop:module --no-interaction install "ps_accounts"
 }
 
 ps_eventbus_install() {
-  # Some explanations are required here:
-  #
-  # If you look closer to the ./docker-compose.yml prestashop service, you will
-  # see multiple mounts on the same files:
-  # - ..:/var/www/html/modules/ps_eventbus:rw        => mount all the sources
-  # - /var/www/html/modules/ps_eventbus/vendor       => void the specific vendor dir, makint it empty
-  # - /var/www/html/modules/ps_eventbus/tools/vendor => void the specific vendor dev dir, making it empty
-  #
-  # That said, we now want our container to have RW access on these directories,
-  # and to install the required composer dependencies for the module to work.
-  #
-  # Other scenarios could be imagined, but this is the best way to avoid writes on a mounted volume,
-  # which would not work on a Linux environment (binding a volume), as opposed to a Windows or Mac one (NFS mount).
-  chown www-data:www-data ./modules/ps_eventbus/vendor
-  chown www-data:www-data ./modules/ps_eventbus/tools/vendor
-  run_user composer install -n -d ./modules/ps_eventbus
-
+  # Notice: you might enable this if your uid is not 1000, or encounter permission issues
+  # composer install -n -d ./modules/ps_eventbus
   echo "* [ps_eventbus] installing the module..."
   cd "$PS_FOLDER"
-  run_user php -d memory_limit=-1 bin/console prestashop:module --no-interaction install "ps_eventbus"
+  php -d memory_limit=-1 bin/console prestashop:module --no-interaction install "ps_eventbus"
 }
 
 ps_accounts_mock_install