Will Jones 043bab6c52 Respect existing stack configuration when initialising secret managers (#17465) ... In #17387 we modified `stack init` to persist an initial secrets manager as part of stack creation (in contrast to only persisting it on subsequent updates as needed). As part of this change, we made it possible to create secrets managers without an existing stack. In doing so, we assumed that the absence of a stack also implied the absence of stack configuration. Consequently, we introduced a bug -- if a user had supplied a stack configuration (e.g. `Pulumi.<stack>.yaml`) *prior* to creating a stack (`dev` in this case) in the backend, we would ignore that configuration and potentially clobber it with a fresh (and likely useless) secrets provider. This was flagged in #17457. In this commit, we refine the new pre-creation secrets manager initialisation code so that it will attempt to load a configuration even in the absence of a stack. If one is found, and configuration *for the type of secrets provider supplied to `stack init`* is found, it will be respected and we won't clobber existing values. Fixes #17457		2024-10-03 15:40:39 +00:00
..
pending	Respect existing stack configuration when initialising secret managers (#17465)	2024-10-03 15:40:39 +00:00
config.yaml	Make pulumi install work for policy packs (#16438)	2024-06-21 19:19:21 +00:00