Use dcfg in-container for app configurations#24
Use dcfg in-container for app configurations#24tannerjfco wants to merge 11 commits intoddev:masterfrom
Conversation
and
Are the CLI flags still respected/maintained? Otherwise this feels a bit like a chicken-or-egg problem to me. Assuming I am understanding correctly, since all our current plugins are all dealing with git checkouts, with this in place the workflow to spin up a new site would be :
If my assumptions are correct, then that feels very disjointed and awkward to me. A few things which might help with the experience:
I read the description of this ticket but did not manually test, so I apologize in advance if I have misunderstood the workflow or ramifications of this change. |
|
@beeradb We have cli flags for hosting that define the app type, but ddev was detecting app type by checking for a couple file paths in the source checkout. That approach is not as feasible w/ varying repo structures, and since we had 2 different ways of handling app type (define via flag in cluster, detect in ddev), my intent with this change is for app type to be determined one way, by reading the You are right that |
|
Tests are now working except for list and workon due to #30. |
|
Applying the fix for #30 I have all tests passing. I'll update w/ the fix here once it's merged in. |
|
Closing this as it is against the defunct legacy plugin, and we are not introducing dcfg at this time. |
The Problem:
See main problem def in #7. We need to not assume a site's repo will be structured the way newmedia has been doing.
The Fix:
This PR updates the legacy plugin to leverage the new dcfg functionality in the container. Only the minimal changes to make this work have been made for legacy plugin, and no changes for drud plugin, as we are likely to focus on local file and I don't want to spend time heavily in areas that may undergo heavy change or removal.
Change summary:
drush.settings.php, not sure if it should stay here or go to dcfg as well)The Test:
You will need the
drud/nginx-php-fpm:dcfgimage to test this change.I've updated the clean test sites to add
drud.yaml. I'm also using their staging branch to test variation of the repo structure:If desired, you should also be able to take another site and configure a drud.yaml file for it referencing the documentation provided here: https://github.com/tannerjfco/dcfg/blob/a3b37c11f9d67b8c9575bd71d20cb2d26ef7deaf/docs/template-task-type.md
Generally the expected result should be that you can spin up any of those sites and have it work. A "stock" drupal or wp site should spin up the same as a newmedia structured site. This should also allow for other permutations of custom repo structures, but these are going to be difficult to test while still reliant on newmedia archives. If there is a permutation that someone feels is important, we can discuss adding it.
Automation Overview:
The test update here is to change the set of test sites to the new clean test sites that now have a
drud.yamlconfigured and committed.Related Issue Link(s):
#7 - primary issue
drud/dcfg#5 - dcfg template plugin PR
drud/docker.nginx-php-fpm#28 - updates to the main nginx container
drud/general#79 - update for in-cluster usage
Release/Deployment notes:
Does this affect anything else, or are there ramifications for other code? Does anything have to be done on deployment?
We need to update drudapi/drud host cli for this functionality as well. That issue is captured at drud/general#79