Here's the remaining list of issues @curved-intern-91221 put together at the end of the last session: https://github.com/garden-io/garden/issues/2775 https://github.com/garden-io/garden/issues/2704 https://github.com/garden-io/garden/issues/2703 https://github.com/garden-io/garden/issues/2702 https://github.com/garden-io/garden/issues/2674 https://github.com/garden-io/garden/issues/2458

About the requests relating to `generateFiles`—the only thing that's really changed there post-0.13 is that we've essentially deprecated the functionality (we're only supporting it for modules, not for actions). I suggest we: * Write a section or two for the [Config Templates](https://docs.garden.io/using-garden/config-templates) page about how to use Build actions in your config templates to fulfil the same function that

generateFiles

used to (which is more flexible and doesn't have the issues/limitations of

generateFiles

). * Once the guide has been updated, close all

generateFiles

-related issues, and reference the guide in the closing comment. The angle there being: "If you're having problems with

generateFiles

, please follow the Config Templates guide to update your config templates to generate actions instead".

That leaves three issues, adding some initial thoughts on each of them here: [[FEATURE]: provide variables that return the path relative to the project root](https://github.com/garden-io/garden/issues/2704) This would be convenient when writing config templates that use Build actions to do

generateFiles

-like things. We do already provide the following paths: * `local.projectPath`: The absolute path to the project root directory. *

actions.<kind>.<name>.sourcePath

and

buildPath

, the local path to the action source and build directories (see

ActionReferenceContext

). The path being requested in the issue is essentially just the relative path from the project path to the action source path, so doing that calculation in whatever script is being wrapped in a

generateFiles

-like Build action should be simple. That said, it would be nice to add

relativeSourcePath

  and

relativeBuildPath

to

ActionReferenceContext

for convenience's sake. It would be a very simple addition (both to implement and to unit-test). [Setting dev mode up to sync a non-existent local directory fails silently](https://github.com/garden-io/garden/issues/2702) I think this should no longer fail silently, at any rate, since as of 0.13 we now log sync problems pretty clearly. So I think we should close this one. [cleanupCommand script fails in exec module fails](https://github.com/garden-io/garden/issues/2458) I'm not 100% sure what's going on here, but I definitely think it's worth a closer look. I suggest we do a preliminary investigation to figure out what the root cause is here and whether it's a quick fix, or whether addressing this would require (potentially scary) changes to the build sync flow.

CC @curved-intern-91221 @freezing-pharmacist-34446 @astonishing-tomato-18259

Also CC-ing @chilly-gigabyte-83853

> cleanupCommand script fails in exec module fails > > I'm not 100% sure what's going on here, but I definitely think it's worth a closer look. I suggest we do a preliminary investigation to figure out what the root cause is here and whether it's a quick fix, or whether addressing this would require (potentially scary) changes to the build sync flow. 1. When do we delete files from the .garden/build directory? If at cleanup it might be just a question of reordering a bit. 2. We should also take a look at how this looks in bonsai, since there we build in the action dir by default and only build in the .garden/build dir if specified explicitly in config.

So, we can remove the reexamine label and consider it as a valid issue