Allow environment specific .yml file definitions & ability to share duplicate .yml files

[mackermedia]

Currently it checks the directory with the name of your environment for .yml files. It sounds like on chron project, production & integration were symlinked to the development dir.

We have a use case on a current project where we want to define two different .yml files (one per environment) for one resource type, but would like to have a shared .yml file for another type of resource.

Thinking this could be accomplished by putting .yml files that can be "shared" into a shared directory.

Thoughts?

[ltk]

yeah agreed. that symlinking feels rather weird. 👍

[Fosome]

@ltk @mackermedia This talk this one through.

[mackermedia]

I liked @Fosome's ideas in his gist for defining shared resources.

I hadn't put much thought into it yet other than I'd like to share a resource like PropertyType without needing to override it. Was just thinking some of the resources could be shared, others could be environment specific.

I think it makes sense to allow shared things to run first, and then if you want to customize in one particular environment you could override or add to them. I can picture a scenario where you want an empty (or missing) file for production environment to not create any of a certain type of resource.

[gcapizzi]

Is there a workaround to share all seed data between environments?

[mackermedia]

@gcapizzi Not yet. This issue was created as a reminder for us to work on this at a future time. Feel free to fork, implement, and submit a Pull Request and we'll get it in as soon as we can.

Thanks!

[ltk]

@gcapizzi The effect you're after can be achieved by creating symlinks with the names of your environments, all pointing to a single directory of your choice. Symbolic links are respected by git, so you shouldn't have any issues.

This is definitely an area focus for our own development moving forward.