SAM Creates stage named "Stage" by default?

[sdole]

I have a template like this:

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Resources:
  Api:
    Properties:
      StageName: dv01
      DefinitionUri: api_spec_SAM.json
    Type: AWS::Serverless::Api

After package and deploy with the cli, it creates an API with two stages named "Stage" and "dv01". In reality, I do not want to create either stages. The StageName property is "required". Not sure why. My intention is to create a separate set of templates to create the stages, deployments, lambda function versions etc.

The reason I need separation is because we have multiple code pipelines that are owned by different people (dev, build teams). I would like these templates to live in separate git repos.

Is there a way to create an API without any stages?

Else, the work around is to simply ignore this one default stage created via SAM. Thanks!

I am also seeing this issue, however I do require a stage set in the AWS::Serverless::Api resource but I am seeing a second stage created as "Stage". I validated in the "processed" cfn template the resource AWS::ApiGateway::Stage is referencing a AWS::ApiGateway::Deployment but the stage name in the deployment is "Stage" not "qic" as set in the stage resource.

SAM Template:

ARSAPIGateway:
    Type: AWS::Serverless::Api
    Properties:
      DefinitionUri: apigateway/swagger.yaml
      StageName: qic
      Variables:
        LambdaFunctionName: !Ref LambdaFunction17

Processed CFN Template:

"APIGatewayDeploymenta727bb8729": {
      "Type": "AWS::ApiGateway::Deployment",
      "Properties": {
        "RestApiId": {
          "Ref": "APIGateway"
        },
        "Description": "RestApi deployment id: a727bb872967fd6e7bd621271f597376226329ee",
        "StageName": "Stage"
      }
    },
"APIGatewayStage": {
      "Type": "AWS::ApiGateway::Stage",
      "Properties": {
        "Variables": {
          "LambdaFunctionName": {
            "Ref": "LambdaFunction17"
          }
        },
        "RestApiId": {
          "Ref": "APIGateway"
        },
        "DeploymentId": {
          "Ref": "APIGatewayDeploymenta727bb8729"
        },
        "StageName": "qic"
      }
    }

Looks like the same/similar issue as here #176

[hagoss01]

I am having a related problem.

I am defining my swagger template inline and in it, the stage name "prod". During the deployment of the stack, I get an error regarding the stage name when another resource (api key and usage plan) tries to reference it. It appears that it doesn't exist (yet the Stage stage exists). It appears that the the processed template includes the "Stage" stage but the creation of the prod stage happens in the wrong order and there is no way to set a "DependsOn"

[mikecbrant]

You see similar (undesired?) behavior when defining AWS::Serverless:Function with API events and not using AWS::Serverless::Api. You end up getting an API gateway resource defined both stage and prod stages, when in reality only a single stage was really desired in that the stacks are being deployed using CodePipeline, where I was hoping the ownership over "Stage". At each stage in this pipeline an instance of the stack defined by the SAM template is deployed. As such, it seems odd to have two API gateway stages (stage/prod) deployed for each on my three CodePipeline-defined stages. Should default behavior be to only create a single single on API gateway rather than two?

[davewoodward]

I'm curious if any of the maintainers of this repo are ever going to weigh-in on this. It makes zero sense to me that both a stage and prod stage are created by default. @sanathkr

[jfuss]

@davewoodward To my knowledge this was and is a bug in SAM. We attempted to remove this behavior but that caused #168 and the fixed was needed to rollback.

The short answer is yes we are aware this happens but right now do not have a good way to fix it that would not cause a regression to all existing stacks that use SAM. There are a couple issue spread throughout this repo on this. We will be working towards cleaning these up into one issue soon. These are the ones that seem related at first glance: #176 #67 #78

[mikecbrant]

@jfuss it would seem that perhaps addition of a property on the resource to determine desired deployment behavior would be feasible, so long as in absence of such a property, the current stage/prod deployments would be the default behavior to maintain backwards compatibility. Of course adding new properties, especially ones that would in essence disappear during the transformation step, might not be desirable either.

[jfuss]

@mikecbrant I personally don't like that approach because you are adding in some property that has no true meaning, other than to hide a bug. This seems like the wrong way to approach a problem like this. The other issue I foresee, is with new customers adopting SAM. Without context of the issue, it is easy to leave this new property out and get into the state we currently are in. Maybe if done correctly, we could do something like this but requires a much deeper discussion and investigation.

Yes, having this stage there is annoying but is it really that harmful? Are there more issues with this other than it is created and is not updatable? Understanding this will help us in trying to prioritize it and give us a bigger reason to dig into it further. When we tried to roll out a fix for this in the past, we caused a regression for customers (#168). Until we have a good solution, the best advice is to just ignore this 'Stage' stage. This is no way ideal by any means but the best I can offer, as of now.

[jarruda]

The version of the transform is in the name (AWS::Serverless-2016-10-31). The purpose of versioning is to allow you to introduce backwards-incompatible changes, right?

While I can see not wanting to increase the version for a seemingly inconsequential bug, it is nevertheless a bug until such time that it's documented as expected behavior.

[jfuss]

@jarruda I have brought this up with the team in the past. I forget how that conversation went but there was some reason we didn't want to do that right now, if I remember correctly.

Regardless, I think we need to invest more time into this issue before taking this approach. We want to make sure we don't have another option to solve this but may be our only option. I will try to drive a conversation with the team, to see if we can get something moving on this. Or at very least communicate to everyone clearly what is going on and where we are at on it.