Support tag --force in serverless-compose

pdias94 commented 1 year ago

Is there an existing issue for this?

[X] I have searched existing issues, it hasn't been reported yet

Use case description

Currently in my company I need to deploy in CI pipelines my lambda functions to multiple api gateways based on microservices by domain.

We need the deploy to ALWAYS run on the api gateway to the given stages.

Currently, serverless-compose don't have this feature.

Proposed solution (optional)

Support the --force tag in deploys using serverless-compose as same as the serverless default deploy

medikoo commented 1 year ago

@pdias94 PR's welcome!

calebplum commented 9 months ago

+1 for this - sometimes if a service deployment fails, subsequent deploys result in no changes and won't actually deploy.

For example, consider a serverless-compose stack with two services:

Service 1 is a Lambda function designed to be run as Lambda@Edge
Service 2 is a Cloudfront distribution that is dependent on Service 1
Service 1 exposes the Lambda ARN to Service 2 via serverless-compose
You run serverless deploy and Service 1 (the Lambda function) deploys successfully, however Service 2 (the Cloudfront distribution) fails to deploy because the Lambda function's trust policy in Service 1 doesn't permit it to be invoked by edgelambda.amazonaws.com.
You fix the trust policy in Service 1 and re-deploy both services via serverless deploy
Even though Service 2 failed and needs to be re-deployed, Serverless will refuse to deploy it again because none of the code in the service has been changed since the last deploy.

It's annoying because you can't just cd into Service 2's subdirectory and deploy it, since it's depended on the ARN provided in Service 1's output.

Another example is if you were to update the function code in Service 1 and want the Cloudfront distribution to point to the new version (that's passed from Service 1 to Service 2 via serverless-compose), serverless-compose won't deploy Service 2 if its template hasn't changed. I assume this is because serverless-compose doesn't take into account changed inputs when determining whether to deploy a service.

Supporting a --force option in serverless-compose would give a convenient way to deal with this.

hpandelo commented 2 months ago

+1 Please!!! It's vital sometimes. I'm spending almost all day redeploying things and checking if the version was affected or not

serverless / compose