I’ve made a brief video describing this use case here:
However in short when there’s a common config that shows up many places we resort to using references. This is great. However in the project that pulls them in you can’t actually see the value of the generated item (nor can you see any pulled in notes for keys that are pulled in). This makes it difficult to know if what you’re looking at makes sense or it may be garbled before releasing or testing locally (with the doppler-cli command ‘doppler secrets’).
I propose a way for the UI to at least see fully interpolated secrets that fill in referenced values for ease of use.
Thanks @avaitla16 for the awesome feedback and killer video!
Lots of great ideas that I’ll make sure get shared with our engineering team and I’ll reply back once I get a better idea of how we may tackle some of the challenges you’ve surfaced here.
Thanks @ryan-blunden . The “root config / common config store” idea is special since often times theres a key that is used multiple places that never changes (for instance mailgun only has one api key, the primary database dns never changes, stripe keys are fairly static). The reason you want to use references though is so that rolling keys become easier (only roll it in one place when needed). We can simulate it as a project which works, but I wonder if it makes sense to annotate it visually somehow (as the root storage). More importantly when referenced else where it should show the full value when rendering in the UI (and ideally could pull in notes if possible).
