:wave: Any tips or ideas how I can speed up my see...
# seed
a
👋 Any tips or ideas how I can speed up my seed deploys for "noop" commits? Looking at our pipeline breakdown we have the following for a commit that doesn't change any lambda or infra code: 1. Restoring dep cache: 12s 2. Install deps: 3s 3. Build: 38s 4. Publishing assets: 80s 5. Deploy: 19s Bringing the total time to around 3 minutes (I skipped a few smaller steps). It seems like the publishing assets step is taking unreasonably long time compared to everything else. Looking into the step logs I see a lot of
no changes
+
checking if we can skip deploy
and then
skipping deployment
. Any way to speed this up?
d
As per my question right above yours, picking a bigger build machine helps a lot. It's an easy change and easy to test. Worth a try.
a
We were already on Medium, but let me give Large a try.
f
@Akos what’s this file u changed that’s not Lambda or infra? Somethign that ideally shouldn’t trigger a deploy?
a
Like 0 files. Just did it with an empty commit. I see a few
sst.Script
resources being "deployed" (even though we only specify
onCreate
) but everything else is no deploys.
83 seconds on a large machine so no significant changes there
@Frank DM-d you an example empty commit build.
f
Got it! Oh how do u generate an empty commit 😂
a
Copy code
git commit --allow-empty -m "empty commit"
f
ah I see.. r u going to regularly have empty commits down the road? Curious on the use case?
a
No, we don't just do empty commits 🤣 But commits that touch: • only tests • docs / READMEs • literally any other file in our monorepo that doesn't impact infra or app (scripts, config files for CI, package.json scripts, etc.) But I'm using an empty commit is just a baseline, i.e. as in "it can't get any faster than this". And currently that number is at 3 mins which I'm looking to see if there are any ways to improve. Getting it down to 2 mins would be already nice.
Any ideas on this or is this just how quick the publish step is?