https://pulumi.com
Join Slack
This message was deleted.
# pulumi-deployments
s
This message was deleted.
l
What language are you using, and do you have policy as code configured?
a
Using Go, and no policy as code
I've tried in different stacks in the same project and the same happens with all I've tried
The "View Live" link that's provided at the start of the preview just shows a spinner in the preview pane for about 3.5 to 4 minutes on average before the preview run begins proper
l
I would guess that this is due to a recent regression in memory consumption in the compile step which we're working on fixing: https://github.com/pulumi/pulumi/issues/14344 When you run a preview, the first thing that happens is 
go run main.go
(or equivalent). Though if this is the cause, I would expect you to see similar behavior in GHA assuming you are using default runner sizes.
a
Interesting. Yeah, the behaviour I'm seeing is only when triggering via a Deployment. Triggering from a local run or via GHA starts up much faster.
I ran a trace profile when triggering a preview from a local CLI call and, end-to-end, the preview returns consistently in around 30s
l
Are you using default GitHub Actions runners (8GB RAM)? Is it the exact same repo/project you are comparing? An older project that hadn't updated to more recent provider SDKs would not see these problems. But in theory, the same code on GHA and Deployments with the same memory and same version of dependencies should have the same performance characteristics.
a
Yes, default GHA runners, exact same repo/project (and even the exact same changes).
e
This is a really curious difference, I'm sorry you're experiencing that. There might be a few factors in play but I am wondering if GHA's support for build caching is making a big difference here.
If you're using something like actions/setup-go as we do [internally](https://github.com/pulumi/pulumi-aws/actions/runs/6712451436/job/18242044336#step:5:47) one of the benefits is that it preserves go compilation cache across build runs. This can make a substantial difference for Pulumi Go programs as we have a significant dependency set, and recompiling it from scratch does add up.
a
We are indeed using 
actions/setup-go
, though do you have any ideas around why triggering a preview locally also starts up very quickly? The only place I'm seeing the diff in latency is when triggering via Deployments. I've cleaned up and forced rebuilding from scratch locally and it completes in the same ~30s window
Well, a bit longer than 30s, but not enough to account for the difference, unless maybe if Deployments is pulling every package, then compiles, it might add up.
e
I've cleaned up
Which commands do you use to clean up?
Copy code
go ​clean -modcache && go clean -cache # perhaps
It's quite possible that my guess is off and something else is in play though, as you point out. Very interesting to understand this so we can improve deployments.
a
yep exactly, and then 
go build -a main.go
🙏 1
the slowest I've seen it run is just shy of 2 minutes
👍 1
l
I would guess that the specs on your local environment are beefier than the VM running the deployment/GHA. Running a build in a docker container constrained to a single cpu and 8gb of RAM allocated would likely produce closer results.
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