https://pulumi.com
Join Slack
This message was deleted.
# typescript
s
This message was deleted.
s
i wonder if pushing infra to the array that will be fed to 
pulumi.all({group1, group2})
and then doing dot notation 
.apply([...groups])
would work and not break pulumi plan tracking?
l
You want to output the ASGs.. do you mean, you want to export them as stack exports? You can use ... notation for this, and you don't need 
all()
or 
apply()
.
If you mean, you want to use some properties of the ASGs in an 
apply()
, then the answer depends on what's happening in the 
apply()
. If it's a simple 
<http://pulumi.info|pulumi.info>.log()
or similar, then you can use the ... notation still. If you're creating more resources, then plan tracking will break, and you'll need to find another way to solve the problem.
s
i guess it might be a little hard to follow, but I'm having difficulty with outputting things that might only exist in certain stacks, like in a primary web region
things that are conditionally created based on a configuration boolean flag for example
l
I don't know what "outputting" means in this context. If you create something conditionally, what's stopping you from "outputting" it, either conditionally or unconditionally (may be undefined)?
s
right so by outputting I mean exporting resources, so say I conditionally created a cron server in one web region and tried to get that output in another projects stack, that output is actually undefined for this corresponding stack but I wouldn't know that at the time the plan is made
is this just kind of a common problem you run into or is there some way to work around this
well I would know that, but pulumi does not
l
If it's just exporting, and you want to export "all the things" without explicitly naming them all, then you can push them into an array and export the array?
The conditional things won't get pushed in some stacks, the code will continue to work and be correct in all stacks.
s
ok that was my intuitive thought as well, i'll run with that idea
thx
l
That said, you'll find when consuming those exports, that naming and exporting them one at a time will make life easier for the consumer of the stack (usually).
s
yeah that's been my usual process, and what I ended up doing with the first example, but i've gone with array exports for large collections, for instance a collection of sqs queues
l
If you implement your infra in a spec-first / test-first "fulfill my ultimate requirement and let my stack design evolve", you'll find how you need to access those exports before you create the code that does the exporting. This will save implementation time by designing the correct API before the implementation.
s
right, i'll keep that in mind as the project grows, thx for your help
so yeah just confirmed that this does work:
Copy code
export const metricAlarms = pulumi.all(_metricAlarms).apply(([...alarms]) => alarms.map((alarm) => {
    return {
        id: alarm.id,
        arn: alarm.arn
    }
}));
i get the stripped down export I want and can simply just add new MetricAlarms to the _metricAlarm array
👍 1
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by