Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Update application container type when type changes in platform.app.yaml #73

Open
gilzow opened this issue Dec 9, 2022 · 3 comments

Comments

@gilzow
Copy link
Collaborator

gilzow commented Dec 9, 2022

Scenario:

Project is cloned locally using platform get <projectid>. Project is configured to use type: "php:7.4" in .platform.app.yaml. DDEV+ddev-platformsh is used to develop locally. Upstream changes occur, changing the type to php:8.1 with composer updates and other changes. git fetch & git pull are used to update the local copy of the repository. DDEV is restarted.

Expected outcome: web application container is update to reflect the updated type (php 8.2) in the application.

Actual outcome: web application container remains the same as initially configured (i.e. php 7.4)

Ideally, there would be a warning that the current platform configuration files are different from the ddev configurations and that a rebuild (possibly a ddev rebuild command?) needs to occur.

Only way I know to "fix" the application container currently is to either rerun the ddev get platformsh/ddev-platformsh command and walk through all the steps, or manually update the the .ddev/config.platformsh.yaml and then do a ddev restart.

@rfay
Copy link
Member

rfay commented Dec 9, 2022

This is important. It's not really compatible with the current design, where all configuration is generated during ddev get, but it's worth strategizing about.

@rfay
Copy link
Member

rfay commented Dec 11, 2022

It's possible we could reorganize things so that ddev getgets the tools to evaluation the platform yamls, and those are used at the end of the ddev get and could also be used pre-start or something, or by a custom command to update.

@gilzow
Copy link
Collaborator Author

gilzow commented Dec 12, 2022

Looks like this could also tie into #61 (ie the potential need for a ddev rebuild command)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants