mojo specs should support a common/shared folder to avoid cluttering top level directories in mojo specs

[Tom Haddon]

Mojo currently supports a structure where script/phase files (such as collect, repo, deploy, etc.) in the top level of spec directory can apply to any stage, and also where stage-specific deployment files can be combined with top level files. This is a very useful setup, as it means you don't need to duplicate things between different stages.

However, it does mean that the top level of a mojo spec can get very cluttered. Mojo should support a "common/shared" folder which any stage can pull from without having to duplicate/symlink everywhere.

This would allow us to go from this:

./service1/
./service1/manifest
./service1/collect
./service1/repo
./service1/deploy
./service1/production/deploy

To this:

./service1/
./service1/manifest
./service1/common/
./service1/common/repo
./service1/common/deploy
./service1/production/deploy

We'd then have a much cleaner "top level" directory of "manifest, common, production" rather than "manifest, collect, repo, deploy, production". Obviously in this case it's not a massive difference, but in the case of lots of scripts/phases that are common to multiple stages this can proliferate quickly.

[Jacek Nykis (jacekn)]

IMO this change would impact user experience and increase learning curve.

For example right now mojo will look for:
./service1/deploy
./service1/production/deploy

And after the change it will look for:
./service1/deploy
./service1/common/deploy
./service1/production/deploy

or maybe:
./service1/common/deploy
./service1/deploy
./service1/production/deploy

It's one extra location to be aware of and it's not very obvious at first glance. It also means that every user needs to read docs to find out in what order files are processed (or find out the hard way)

We could work around it by removing support for placing deploy/repo/collect files in the top directory but that would break every spec out there.

[Paul Gear (paulgear)]

Next steps are probably some wider discussion on which is a clearer approach, and a review of the example project and the documentation in the light of both options.