All in all it takes about 5 6 minutes just for a preview to

Question

All in all it takes about 5 6 minutes just for a preview to complete whereas the same op started locally takes about 30s in total

lemon-agent-27707 · Answer

What language are you using and do you have policy as code configured

ambitious-air-92938 · Answer

Using Go and no policy as code

ambitious-air-92938 · Answer

I ve tried in different stacks in the same project and the same happens with all I ve tried

ambitious-air-92938 · Answer

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

lemon-agent-27707 · Answer

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

ambitious-air-92938 · Answer

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

ambitious-air-92938 · Answer

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

lemon-agent-27707 · Answer

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

ambitious-air-92938 · Answer

Yes default GHA runners exact same repo project and even the exact same changes

enough-garden-22763 · Answer

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

enough-garden-22763 · Answer

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

ambitious-air-92938 · Answer

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

ambitious-air-92938 · Answer

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

enough-garden-22763 · Answer

gt I ve cleaned up

enough-garden-22763 · Answer

Which commands do you use to clean up

enough-garden-22763 · Answer

``` go clean modcache amp amp go clean cache perhaps```

enough-garden-22763 · Answer

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

lemon-agent-27707 · Answer

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