Open mnapoli opened 2 years ago
As discussed in our call, one of the potential options here would be to use a "hidden" internal component that will handle the management of the bucket used for deployments.
I think this should even be the default behavior, but putting this single line in serverless-compose.yml
is not bad.
For now, I tried to pass ServerlessDeploymentBucketName
as a param (since sls creates such output), but serverless-compose did not see it and thrown an error:
name: myapp
services:
common:
path: services/common
api:
path: services/api
params:
deploymentBucket: ${common.ServerlessDeploymentBucketName}
@m-radzikowski thanks for the feedback!
And regarding your error, oh it seems to be related to this:
I explicitly removed that line from info
(and outputs) to avoid having too much noise. I didn't think about this use case 🤔 I'm not sure if we should restore that output, wdyt @pgrzesik?
useless info
😄
This will not be needed if the deployment bucket is shared automatically thought.
Thanks for the feedback @m-radzikowski 🙇
@mnapoli I think it's good to keep it in outputs for the exact use case that @m-radzikowski has here - we can remove it afterwards if needed
👍 sounds good to me!
Note: this may be related as well to state storage (on S3) and/or CDK deployments with the bootstrap stack.
There may be an opportunity here to have 1 bucket per app, and use it to store state + as deployment bucket for services.
Feature idea: a way to automatically share the deployment bucket across all Serverless Framework services.
For example:
and automatically all services share the same deployment bucket (no extra config needed).
It needs to be opt-in of course (to preserve backward compatibility).
Thoughts?