Why mount $XDG_DATA_HOME and $XDG_CONFIG_HOME as caddy_... directories?

[goulashsoup]

The frankenphp image sets $XDG_DATA_HOME = /data and $XDG_CONFIG_HOME = /config and in the compose.yaml these directories are mounted like this:

    volumes:
      - caddy_data:/data
      - caddy_config:/config

1. As these are just the XDG_ directories of the container OS, isn't is more fitting to mount these as container_data and container_config ?
   Cause the Caddy stuff is in /data/caddy and /config/caddy which is mounted as caddy_data/caddy and caddy_config/caddy, also then there are other /data and /config files that show up in the IDE like caddy_data/composer and caddy_config/composer...

2. Or was the intentation to ONLY mount the caddy stuff?
   (Then it should be - caddy_data:/data/caddy and - caddy_config:/config/caddy ?

3. Also it is not clear to me what the intent was to mount /data/caddy and /config/caddy anyway?
   /data/caddy/certificates/local/localhost and /config/caddy/pki/authorities/local as well as other data/config stuff will be created/changed by Caddy anyway (same for /data/mercure.db).

4. Or is the Caddy stuff mounted for debugging purposes?

5. Additionally: I also wonder if I should commit some or all of the /data and /config directory in my git repository?
   Otherwise I would have expected an initialisation step in the make file that will add caddy_data and caddy_config to the .gitignore that will be created by Symfony on first run.

6. Or is there a benefit by saving stuff from /data/caddy/certificates/local/localhost and /config/caddy/pki/authorities/local in the git repository (other then a coworker not having to wait for the initial setup)?

@dunglas Can you check these questions?

Maybe there is some improvement to clarify why mount /data, /config and what to save in the git repo...

Thank you very much for your time.

[dunglas]

This behavior is inherited from the official Caddy images: https://github.com/caddyserver/caddy-docker/blob/master/Dockerfile.tmpl#L42-L43

The volume's name is prefixed by caddy_(it could be frankenphp_ now) because it contains data from the Caddy/FrankenPHP container (not from the DB container for instance).

The purpose of this volume is to store and share TLS certificates automatically generated by Caddy (including in prod mode). These certificates shouldn't be versioned in Git.

[goulashsoup]

The purpose of this volume is to store and share TLS certificates automatically generated by Caddy (including in prod mode).

This still does NOT answer why they are mounted in the first place?

[dunglas]

As explained, these volumes (which are not bind mounted) are necessary because the content of these directories must be shared between the different Caddy container instances and persisted between restarts.

[goulashsoup]

The only files for which I can understand this, are the root certificate files for local development, but why do /data/caddy/certificates/local/localhost and /data/mercure.db need to be persistent across restarts?

If they are missing, they will just be created again.

Also the composer is also persistent with this mounting...

@maxhelias Why did you did mark this as answered?

There is not SPECIFIC reason given anywhere in these responses...

If you don't want to give support for your stuff, just disable the QA...

[dunglas]

What's the point of "creating them again" at every restart, and for instance, losing, events stored in Mercure's DB or the Composer cache, instead of reusing them across restarts?

I don't get your point at all.

Removing these volumes will just lead to poor DX.

We use volume to store Postgres data for the exact same reason.

[goulashsoup]

What's the point of "creating them again" at every restart, and for instance, losing, events stored in Mercure's DB or the Composer cache, instead of reusing them across restarts?

Removing these volumes will just lead to poor DX.

OK, thank you very much! ❤️

That was a more straight answer. 😉

I might come back to that later, maybe there are some "issues" because of this in regards to mercure or composer when a user expects a "clean slate" after a restart.

@dunglas Can I create a PR renaming this (see below)?

    volumes:
      - php_container_xdg_data:/data
      - php_container_xdg_config:/config

This more self-explanatory and explicit about "what we are actually" mounting.

I also propose to add a step to the make file that will add following section to the .gitignore after the Symfony project was created:

###> mounted xdg directories
/container_xdg_config
/container_xdg_data
###< mounted xdg directories

Again thanks for you time ❤️