Hi @Frank , Thank you to the entire sst team for making it easy to work with serverless apps. Here is my query, can we have reusable artifact in the context of CICD separate build and deploy pipelines. For example, the serverless framework has support of using the same build for deploying without rebuilding by referencing the path to the build and can be found in this blog. Is this something that the sst can support? I can see an open issue ,but our context is on separate build and deploy pipelines.

Hey @Kiran Siddagangappa, just to confirm, you are looking to do:

sst build --artifact apth/to/artifact

and then

sst deploy --artifact path/to/artifact

something like this?

@Frank Functionality wise, yes that's correct. Having said that, even if sst does not give --artifact flag to upload/download, it should be fine as long as the sst deploy command would use the .build folder residing on the workspace rather than generating(rebuilding) the new .build folder

@Frank yes that’s the gist of it. I work with Kiran. We like to separate build and deploy pipelines when we can. This allows us to have builds performed on commit with versioned artifacts. These artifacts can then be deployed as is to any of our environments with their paired env variables. This deployment generally uses an approval process and is gated by environment based on a user’s level of access. For instance “service-build-1.2.3” can be deployed to QA by QA team. Once’s tested this same build can be deployed to Production by release managers who are authorized. This is how we do things with Kubernetes, but would like to start an approach like this for lambda. What you suggest with the “artifact” flag would enable this or as @Kiran Siddagangappa suggests even a “build” folder.