Feature: Always deploy API option

[keetonian]

Description:

Add a new property to always deploy your API even if we can't detect a change to the API.

Steps to reproduce the issue:

1. Deploy a SAM template with an API that references a function
2. Change the name of the function
3. Redeploy the template

Observed result:

The rest API does not redeploy with the updated function name

Expected result:

Rest API would redeploy with the updated function name

See issue #634

[jlhood]

Another edge case where a customer encountered an availability drop by a missed API deployment:

In your case, from the name of your functions, I'm guessing you're explicitly hardcoding the function name using the FunctionName property. If you change the value of FunctionName without changing the logical id (key of the AWS::Serverless::Function resource), SAM will not detect that the API has changed and will not redeploy the API after it's been updated.

In this case, on deployment, CloudFormation creates a new function with the new name, updates the API Gateway REST definition to point to the new function name, does NOT do a deployment of this updated API definition (so the actual API is still referencing the function with the old name), then deletes the Lambda function with the old name (causing the API to now return 5xx errors).

[keetonian]

#1162 is another case that this would fix.

[jonathanyong81]

Has there been any progress on this?

For example if my swagger definition has an endpoint with the following

x-amazon-apigateway-integration:
  uri: !Sub "arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/${LambdaFunction.Arn}:${FunctionAlias}/invocations"

When I update the lambda (so a new version of the lambda, with a new alias pointing to that version), SAM doesn't deploy the API. Although the API definition shows the endpoint integrated with the new lambda alias, the stage is NOT actually deployed.

To get around this, we would have to hardcode and increment the FunctionAlias in the swagger definition (so that SAM detects a swagger change) rather than using the variable.

[deepku2]

+1

[atharfaraz]

+1

[SanderAdamDXC]

+1

[ilietrasca]

+1

[elliottyates]

We experienced the same issue when updating an HTTP_PROXY URI and a stage variable using the SAM CLI. The URI shows up in the console/UI, and the stage variable gets changed on the stage, but the actual URI isn't changed (which you can see by exporting the stage spec) until you manually deploy the updated resources (we did this via the console).

[VanOvermeire]

Experiencing the same issue, is this somewhere on the road map?

[ncanibano]

Facing this issue as well. Any updates on when this feature is going to be available? Thanks!

[cb-manideep]

+1

[ni1402]

We also facing this issue with CORS update. ny updates on when this feature is going to be available?

[VanOvermeire]

Our (silly) workaround is to use sed to add a build number suffix to the name of our api gateway resource, thereby forcing a replacement.

Does mean that even if there are no changes, the gateway is replaced. But this seems to add only 5-15 seconds to the deploy, which is acceptable for us. And much better than not getting our new endpoints!

// in our (groovy) jenkins pipeline; ApiGatewayApi is the name of our resource
sh "sed -i'.original' -e 's#ApiGatewayApi#ApiGatewayApi${env.BUILD_NUMBER}#' our-sam-template.yaml"

But obviously still hoping for a real fix :)

[AshMenhennett]

Hi

I believe this is related - #1447

Ran into some issues with API Gateway config changes not redeploying the API - this feature request looks to resolve this issue.

[carlnordenfelt]

Experiencing the same issue when updating a Mock integrations Mapping Template.
There is an update o the API Definition (we inject the API specification via

"Api": {
      "Type": "AWS::Serverless::Api",
      "Properties": {
        "DefinitionBody": ...

it appears that some changes, like updating a Mapping Template, does not trigger an API deployment.

---

Edit:
Seems I might have made a slightly incorrect assumption.
In this particular case the Mapping Template that changed has not actually changed. The value of a referenced parameter that is injected vis `!Sub' has.

Based on this I lean towards not calling this out as a SAM issue but rather a general CloudFormation issue.
That said, an option to always deploy the API regardless of visible changes would mitigate the problem.

For now I am working around it by swapping DefinitionBody for DefinitionUri with a guaranteed unique S3 key:

"Api": {
      "Type": "AWS::Serverless::Api",
      "Properties": {
        "DefinitionUri": {
          "Bucket": "my-bucket",
          "Key": "my/unique-s3-key.json"
        }

[hoffa]

One potential solution that would keep the transform deterministic would be to append a hash of the entire template and parameters to the API resource if a property is set (e.g. AlwaysDeploy: true). 🤔 Although at glance not sure whether you'd want to redeploy even if there are no visible changes; e.g. with references to external resources.

[hoffa]

I'm working on a draft PR in #2935 that adds a new property AlwaysDeploy (disabled by default), which as the name suggests would always redeploy the API, even when neither the template nor parameters have changed.

[hoffa]

#2935 has been merged and will roll out over the coming weeks.