Hi guys, Is there a way to call `npx sst deploy` ...
# sst
Hi guys, Is there a way to call
npx sst deploy
and just do a deploy without building it again?
Hey @Aram, currently no. What’s ur use case?
Hey @Frank, I'm deploying the same code to multiple stages and wanted to avoid rebuilding it every time and just deploy the already built assets to another stage
I see. Generally speaking, it’s safer to build for every stage. Often ppl have stage dependent code (ie.
customDomain: scope.stage === "prod" ? "<http://api.domain.com|api.domain.com>" : undefined;
Well, if you don’t share accounts between stages, most of the resources are changing.
Right, the CloudFormation template is different for different stages b/c the template name and the resource names are parameterized with the sage name.
@Frank I was actually looking for this as well, but my use case is different. My pipelines generally have 3 steps
Source -> Manual Approval -> Deploy
the desired one is
Source -> Build -> Manual Approval -> Deploy Without Build
This would make our deployments much faster because the build does not have to be done twice.
@Frank I'm using the same account for all of those stages, so in general I don't have anything that's different from stage to stage other then the env vars
@geekmidas @Aram Opened an issue for this - https://github.com/serverless-stack/serverless-stack/issues/779
@Aram the tricky thing here is that when you run
sst build --stage dev
, the generated CFN stack name is
, and you can’t reuse the same template to deploy to other stages (ie.
@Frank that's correct, that's a good point, so the question would be is it possible to regenerate only the template and not rebuild the assets?
Yeah, I guess a flag to skip packaging the function code can work for
sst build
, and you can supply previously built assets.
It’s definitely a pretty advanced use case.
@Frank having that would be really awesome, in our case we are deploying the same production stack to multiple stages and it will decrease the deployment time dramatically
@Frank another nice thing here would be to avoid rebuilding before redeploy if there is no codebase change. The use case for that is when there is an issue during redeployment that can be fixed manually from aws console and redeploy it will still build the same code before redeploying again