Problem/Motivation
When a recipe fails to apply, it can be difficult to determine where/when the failure happened, especially in a large recipe stack.
If we could output the what is happening during the application process similar to what composer does, it would help the recipe creation/debugging process.
Steps to reproduce
Change a config file name that other configs depend on in a large recipe stack and apply that recipe.
Proposed resolution
From @alexpott:
We can pass the io object into all the methods on \Drupal\Core\Recipe\RecipeRunner and output information from there.
Remaining tasks
Everything.
User interface changes
None
API changes
None
Data model changes
None
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | recipe-runner.gif | 167.92 KB | alexpott |
Issue fork distributions_recipes-3427558
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
srishtiiee commentedAdded basic logging to the recipe application workflow. The MR needs an initial review for what more can be done here to enhance the debugging process.
Standard recipe application logging looks like this RN:
Comment #5
thejimbirch commentedWow, this is looking really great!
From a functional review, not a code review, you are displaying info for:
Some missing things are we don't see the
config:importhappening, nor when the config folder is imported.While you state when
config:actionsare running, it would also be great to see the individual actions being applied.These last two points are often where most of the issues are when creating recipes and would help give a lot more insight into the process to recipe developers.
Thanks for your work on this! This will be a big help for recipe creators.
Comment #6
phenaproximaWell, I think this is an awesome idea, and I love what the screenshot is showing us!
I think that we do need to change the way this is implemented, though - right now the MR tightly couples the recipe system to the Console component, and that's not a coupling we should do. I think what's really best here is for the recipe system to accept a logger, which will give us a great deal more flexibility.
Comment #7
srishtiiee commented@phenaproxima, thanks! Changed the implementation to injecting a logger instead. Also, added console logging for each config action and config import. It needs another review.
Comment #8
phenaproximaComment #9
srishtiiee commentedComment #10
phenaproximaThis is getting better, for sure. I think we need to make it more robust, and we'll need test coverage.
Comment #11
alexpottThis is blocking making the core patch for recipes and should be part of phase 1 recipes.
Comment #12
phenaproximaTechnically this is not a blocker. But it is part our core MVP, so tagging that way.
Comment #14
alexpottGot a slightly different approach based on the install batching from #3439702: Allow CLI install of Drupal using recipes.
See

Comment #15
alexpottMerged 11.x in now that the installer MR has landed...
Comment #16
thejimbirch commentedApplying the recipe gives much more information with this merge request applied as it runs through the recipe.
Adding the verbose flag,
-v, adds a very nice summary at the end.I edited a recipe that the standard recipe requires to make it error. The error notice appears before the recipe runs and has a very helpful error message, which was the original motivation for this issue.
Marking this as RTBC. It will be very helpful to recipe creators and users! Thanks!
Comment #17
alexpottComment #18
alexpottCommitted and pushed 300b8e0fb98 to 11.x and 74325fd86e2 to 10.3.x. Thanks!
Comment #23
alexpottCherry picked to #3439923: Add recipes api as experimental API to core