Here are a few things that would make my use case of the system better - I can not say how much they would help others
Projects via the web GUI can add a description string against each project. This is then displayed in the project list. Currently, it seems that this string can be set when a project is created, but there does not seem to be any way to modify it via the GUI after creation.
As projects can have a text description it would be helpful for environments and configs also to have such a field.
Can the description string also be configured so that it can be accessed via a special secret name, so as well as supporting ${DOPPLER_PROJECT} you also provide ${DOPPLER_PROJECT_COMMENT}? Also for environments and configs if you extend these to support comments.
This has come up before. I’ve noted that you’re interested in it on our internal issue tracking this!
This is a bit trickier. Our secret referencing system only references actual secrets (there’s no concept of a “virtual” secret that can be referenced with a dynamic value based on the project/config that doesn’t have an actual secret it maps to). As such, adding this behavior would require adding an additional DOPPLER_ variable to every config. That means it would also get synced to third party platforms via integration syncs along with a pretty long list of potential implications. I suspect we would opt not to add this currently unless we had some other way of making it available that didn’t require adding it as an additional managed secret on the config.
Thanks for the reply and detail. It would seem that the idea of having a comment linked to a config is directly connected to the answer you provided for the access to project comment. If you do not have the concept of meta data that is independent of the config data it will be hard to do.
How about a sticky GUI setting that will display a named secret within a config as a comment against the config within the GUI.
The background to all of this is that I’m using Doppler to define “infrastructure as code” configs. The problem is that this then makes the config name a look-up key for the deployment process (such as a MAC address) rather than a human-readable name. This works well for the scripting process but makes the GUI complicated to use.
I already have such a config value defined to allow me to track human-readable text, named ‘__notes’ (the double underscore is there to place the value first in the list). If such a field could be displayed in the GUI it would allow the end user to control the feature without the need for any restructuring of your data model.
