Documenting a conversation @rfay and I had recently.
Two issues.
Currently, this add-on writes the current Platform.sh project configurations to .ddev/config.platformsh.yaml at the state of the project when ddev get <platform> is run. The suggestion, so far, has been to commit this file (and .ddev/config.yaml) to the repository, with the intention that teams are getting the same .ddev configurations. The challenge is that since the platform.sh --> Ddev config setup only occurs once, any changes later on in the platform.sh configuration aren't picked up by ddev. This means that a new team member, especially one new to ddev, may not know the configuration is out-of-sync. Or a change to the configuration that doesn't occur in conjunction with ddev can result in an out-of-sync situation down the line.
This exact situation has already occurred with the platform.sh Drupal 9 template. When the .ddev/config.yaml file was created and committed, the mariadb version was set to 10.3, but at some point later, the version in the platform configuration was updated to use 10.4. This means that anyone using ddev start because the configuration is already there, will end up using a different version locally than what is configured in production.
Ideally we need some way for ddev to either notice when there has been a change to platform.sh configurations, or possibly rewrite the .ddev/config.platformsh.yaml file on every ddev start. Doing the latter would/should eliminate the need to have (or at least not commit) a .ddev/config.platformsh.yaml file.
Another complication is that, particularly in large orgs, the concept of a starting upstream project/repository is used (very similar to our templates). This allows standardization across the projects. Ideally, we could have a ddev config file that sets up a new developer to have most of what they need. In this scenario, we can't use .ddev/config.yaml as that doesn't set up everything they need for a platform integration and we dont want to set PLATFORM_* environmental variables up yet in .ddev/conffig.yaml since the upstream repo isn't connected to a specific project.
Ideally we would have some way to tell ddev that this project should use the platform addon without requiring the user to do ddev get <platform>. Essentially, ddev itself would kick off ddev get and walk the user through setting up the integration. At this point the .ddev/config.yaml file could be committed (since it would now contain the PLATFORM_* environmental variables needed to associate it with a specific project). If we combine this idea with the above, then a user who creates a new platform.sh project based off on a upstream, or clones an existing platform.sh project, would only need to do ddev start in order to get a functional ddev instance that mirrors their platform.sh project.
For inspiration, lando handles this through a recipe property in a config file. However, it's not without its faults. The user is required to create a new local lando.yaml file and add at least a name property, otherwise lando will re-use any existing project with name property as defined in that upstream file.
rfay
commented
1 year ago
Documenting a conversation @rfay and I had recently.
Two issues.
Currently, this add-on writes the current Platform.sh project configurations to
.ddev/config.platformsh.yamlat the state of the project whenddev get <platform>is run. The suggestion, so far, has been to commit this file (and.ddev/config.yaml) to the repository, with the intention that teams are getting the same .ddev configurations. The challenge is that since the platform.sh --> Ddev config setup only occurs once, any changes later on in the platform.sh configuration aren't picked up by ddev. This means that a new team member, especially one new to ddev, may not know the configuration is out-of-sync. Or a change to the configuration that doesn't occur in conjunction with ddev can result in an out-of-sync situation down the line.This exact situation has already occurred with the platform.sh Drupal 9 template. When the
.ddev/config.yamlfile was created and committed, the mariadb version was set to 10.3, but at some point later, the version in the platform configuration was updated to use 10.4. This means that anyone usingddev startbecause the configuration is already there, will end up using a different version locally than what is configured in production.Ideally we need some way for ddev to either notice when there has been a change to platform.sh configurations, or possibly rewrite the
.ddev/config.platformsh.yamlfile on everyddev start. Doing the latter would/should eliminate the need to have (or at least not commit) a.ddev/config.platformsh.yamlfile.Another complication is that, particularly in large orgs, the concept of a starting upstream project/repository is used (very similar to our templates). This allows standardization across the projects. Ideally, we could have a ddev config file that sets up a new developer to have most of what they need. In this scenario, we can't use
.ddev/config.yamlas that doesn't set up everything they need for a platform integration and we dont want to setPLATFORM_*environmental variables up yet in.ddev/conffig.yamlsince the upstream repo isn't connected to a specific project.Ideally we would have some way to tell ddev that this project should use the platform addon without requiring the user to do
ddev get <platform>. Essentially, ddev itself would kick offddev getand walk the user through setting up the integration. At this point the.ddev/config.yamlfile could be committed (since it would now contain thePLATFORM_*environmental variables needed to associate it with a specific project). If we combine this idea with the above, then a user who creates a new platform.sh project based off on a upstream, or clones an existing platform.sh project, would only need to doddev startin order to get a functional ddev instance that mirrors their platform.sh project.For inspiration, lando handles this through a
recipeproperty in a config file. However, it's not without its faults. The user is required to create a new local lando.yaml file and add at least anameproperty, otherwise lando will re-use any existing project with name property as defined in that upstream file.