Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support tag --force in serverless-compose #167

Open
1 task done
pdias94 opened this issue Dec 2, 2022 · 3 comments
Open
1 task done

Support tag --force in serverless-compose #167

pdias94 opened this issue Dec 2, 2022 · 3 comments

Comments

@pdias94
Copy link

pdias94 commented Dec 2, 2022

Is there an existing issue for this?

  • 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
Copy link

medikoo commented Dec 5, 2022

@pdias94 PR's welcome!

@medikoo medikoo transferred this issue from serverless/serverless Dec 5, 2022
@calebplum
Copy link

calebplum commented Oct 1, 2023

+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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants