type PulumiFn = () => Promise<Record<string, any> | void>
, so no function args are allowed without breaking the type. It would work when reading data inside the pulumiProgram from an outer global variable (which has been set from a different part of the code before), but that feels wrong and unsafe. I'm quite certain that I'm not the only one who wants to have some parts of the Pulumi script dynamic, so I'm curious to hear your thoughts! 🙂
Reference: https://www.pulumi.com/docs/iac/using-pulumi/automation-api/getting-started-automation-api/#define-your-pulumi-program
m
modern-zebra-45309
01/20/2025, 1:37 PM
I've solved this using the Pulumi configuration in the past. This gives the most transparency and ensures that any dynamic value is part of the stack's state.
Specifically, we created a data model (
MyStackParameters
) and had a method to add an instantiated data model to the stack's configuration (mapping each field in the data model to a configuration key while taking care of nested fields and type conversions).
In the specific instance, we used the same data model to parse config files and API requests, and it really helped to keep everything in sync across different stacks and programs.
We've created an API that uses LocalWorkspace and passes content from the request body into the program. We ended up doing this:
kind-motherboard-59197
01/21/2025, 7:58 AM
We basically just dynamically create (or select) the stack whenever we have the body, then create an anonymous function that calls another function that contains the actual logic, but accepts a parameter
No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.