Repository navigation
Allow option to merge, or parameters to allow external merging #12
Description
Activity
Hey Warren - I have a fork that does this actually, need to push my most recent update and submit a PR, just need to sanity check that what I've added won't break existing use cases of Configuration
It sounds useful to be able to set a single setting at a specific level ...
As a general case, I don't think I want to support importing a specific layer. Other than this particular scenario of exporting to a specific layer, what's a use case where you'd want to import just one layer and ignore settings at other layers?
What I'd rather do is provide an
Update-Configurationwrapper forUpdate-Metadata, in the same way that:Export-ConfigurationcombinesGet-StoragePathand wrapsExport-MetadataImport-ConfigurationcombinesGet-StoragePathand wrapsImport-Metadata
Update-Metadataupdates a single value in a PowerShell metadata file, so if we added anUpdate-Configurationwith a-Scopeparameter, would that work for your case?Importing a single layer in my case makes managing multi-level configs easier; things tend to get a little messy when with stacking layers due to the complexity of my configs. I leverage the layers to differentiate accessibility to each config only but tend to have module configs which need multiple sub configs at each layer. This also allows me to test and validate a specific layer's config that another user, i.e. a system account, would be using (i.e. Machine) without having to move/replace my User level personal config.
Sample config on my end for a single layer (module functions handles selecting the ConfigName after the layer's imported):
@{ work = @{ Preference = 'CustomerID' P12KeyPath = 'C:\Access\PSGoogle.p12' AppEmail = 'psgoogle@redactec.iam.gserviceaccount.com' CustomerID = 'C12348938' AdminEmail = 'nate@domain1.com' Domain = 'domain1.com' ServiceAccountClientID = '89723478923459782134789' } DefaultConfig = 'work' personal = @{ AdminEmail = 'nate@domain2.com' Domain = 'domain2.com' Preference = 'CustomerID' CustomerID = '09876123' P12KeyPath = 'C:\Access\pers_key.p12' AppEmail = 'personalpsgsuite@redactediam.gserviceaccount.com' ServiceAccountClientID = '329862349862398623986' } serviceaccount = @{ Preference = 'CustomerID' P12KeyPath = 'C:\Access\keyname_for_this.p12' AppEmail = 'psgsuite@redacted.iam.gserviceaccount.com' CustomerID = '12345678' AdminEmail = 'serviceaccount@domain2.com' Domain = 'domain2.com' ServiceAccountClientID = '1234567890123456789' } }
Reacted by Joel BennettI think the main thing I want is for
Update-Metadatato support adding fields that aren't there, and then maybe incorporate that into Configuration as:Update-Configuration -Scope User -KeyName work.AdminEmail -Value nate@newdomain.com
Hiyo!
In some cases, one might simply want to set, or add a property to an existing configuration. As is,
Export-Configurationsimply overwrites everything.I don't see an option to manually merge - if we
import-configurationto get current properties, we have no control over what scope, so it seems awkward to assume we can let the winner of import-configuration override the specific scope a user selects. Maybe I'm not thinking it through though.I see two potential workarounds:
-Mergeswitch on the export, which reads the current config, and adds / updates properties as neededImport-ConfigurationBoth might come in handy depending on your scenario and desire for abstraction.
Cheers!