Initial mapping from `.platform.app.yaml`

ddev / ddev-platformsh

Add integration with Platform.sh hosting service

Apache License 2.0

9 stars 10 forks source link

Initial mapping from `.platform.app.yaml` #7

Closed lolautruche closed 1 year ago

lolautruche commented 2 years ago

Read basic settings from.platform.app.yaml and reflect them into config.platformsh.yaml

Project name
PHP version from type
PHP extensions from runtime
Env variables (basic ones including basic $PLATFORM_ ones))
Mount Names

rfay commented 2 years ago

This really has to read both .platform.app.yaml + .platform/services.yaml right? They're like a poor-man's relational database?

rfay commented 2 years ago

RE: "Mount names", DDEV currently only has a concept of one mount, for example sites/default/files for Drupal or public/fileadmin in TYPO3. It's a limitation of DDEV but one that has rarely been an issue. It's worth considering extending this conceptually in DDEV but I think that might be a nontrivial operation that would help few users. Platform's maturity in supporting multiple "mounts" is much better... but we may have to make tradeoffs with this.

lolautruche commented 2 years ago

This really has to read both .platform.app.yaml + .platform/services.yaml right? They're like a poor-man's relational database?

Yes that's right. Services are actually configured in .platform/services.yaml and referenced in .platform.app.yaml.

lolautruche commented 2 years ago

It would be awesome if DDEV could benefit this improvement 🙂 . In the meantime, I think we could only ensure that directories listed in mounts exist locally, so that the app doesn't fail using files in those. Also, this would ensure that ddev pull doesn't fail on mounts.

rfay commented 2 years ago

https://github.com/platformsh/ddev-platformsh/pull/14 added a basic mapping, including php version.
I'm not sure project name should be mapped, we should think about that. Mostly the project name will default to the directory name, which is often a result of the git checkout.
PHP extensions and PLATFORM_* are still ahead

Can you say more about mount names and why and how they would be used?

lolautruche commented 2 years ago

Platform.sh containers are readonly. However, it is possible to create r/w capable "mounts" within containers for directories that need write access (e.g., logs, uploads, cache, etc). What's important here is that we ensure those directories do exist.

For example:

mounts:
    'web/uploads':
        source: local
        source_path: uploads

web/uploads is the "name" of the mount, i.e. the writeable directory. It's the path in the app container, relative to the docroot.
source: can only be "local". We can ignore
source_path: the path in the external mounted drive. We can ignore it as well.

The only important part in this example is the "name" (web/uploads). We need to ensure the directory actually exists, and to create it if needed on start.

rfay commented 1 year ago

I think this is complete. Closing, followups in separate issues.