Support StateMachine DefinitionUri for local files

[zaus]

Describe the bug

According to AWS docs for SAM-style StateMachine declaration, the DefinitionUri should support specifying a local file path. However, in practice deployment fails.

Expected Behavior

Given a separate file in a subfolder States/state-machine.yml, I should be able to use the following in my serverless.yml template to deploy the stack:

AWSTemplateFormatVersion: 2010-09-09
Transform: AWS::Serverless-2016-10-31
...
Resources:
  StateMachine:
    Type: AWS::Serverless::StateMachine
    Properties:
      Name: !Sub ${AWS::StackName}
      Role: !GetAtt [StateMachineRole, Arn]
      AutoPublishAlias: live
      # DeploymentPreference:
      #   Type: Linear10PercentEvery10Minutes
      PropagateTags: true
      DefinitionSubstitutions:
        MyFnMethod1.Arn: !GetAtt [MyFnMethod1, Arn]
        MyFnMethod2.Arn: !GetAtt [MyFnMethod2, Arn]
      # can't transclude b/c of issue #116
      #DefinitionString: !Sub 'States\state-machine.json'

      DefinitionUri: States/state-machine.yml		<-- this fails

      Definition:						<-- this works if used instead
        Comment: explicit inline declaration
        StartAt: Begin
        ...

Current Behavior

However, I'm getting the same error when trying to deploy as described in 4-year old closed issue aws-cloudformation/cfn-lint#1561

Failed to create CloudFormation change set: Transform AWS::Serverless-2016-10-31 failed with: Invalid Serverless Application Specification document. Number of errors found: 1. Resource with id [StateMachine] is invalid. 'DefinitionUri' is not a valid S3 Uri of the form 's3://bucket/key' with optional versionId query parameter.

Reproduction Steps

See above using DefinitionUri. Replacing it with an inline Definition works so the problem shouldn't be the definition itself.

Possible Solution

Is something using an older transformation version or CDK? As far as I can tell there's nothing other than Transform: AWS::Serverless-2016-10-31 as described here, and you're using almost the most recent CloudFormation nuget package (3.7.307.11 is only 10 days newer than the version referenced here).

Per the definition of DefinitionUri, am I missing something to include the separate file in the deployment process? It's currently set to "None/Copy If Newer".

If you provide a local file path, the template must go through the workflow that includes the sam deploy or sam package command to correctly transform the definition. To do this, you must use version 0.52.0 or later of the AWS SAM CLI.

Additional Information/Context

No response

Targeted .NET platform

.NET 8

CLI extension version

Package Id Version Commands

amazon.lambda.testtool-3.1 0.10.0 dotnet-lambda-test-tool-3.1
amazon.lambda.tools 5.10.4 dotnet-lambda
dotnet-xscgen 2.0.662 xscgen

Environment details (OS name and version, etc.)

Windows 10

[ashishdhingra]

@zaus Good morning. I don't see AWS Extensions for .NET CLI tooling support CloudFormation resource AWS::Serverless::StateMachine. Could you please review if you are using this tooling and share minimal reproducible code?

EDIT: Discussed this with the team. Handling of DefinitionUri could be supported in this tooling.

Thanks,
Ashish

[zaus]

Yes, I'm currently using AWS::Serverless::StateMachine; I was previously using AWS::StepFunctions::StateMachine but swapped them out to take advantage of AutoPublishAlias. I was able to deploy either way when using the inline Definition (basically what's in my original example), but when I try to use DefinitionUri deployment gets all the way past "Found existing stack" but fails at the following:

CloudFormation change set created
... Waiting for change set to be reviewed
Error getting status of change set: Failed to create CloudFormation change set: Transform AWS::Serverless-2016-10-31 failed with: Invalid Serverless Application Specification document. Number of errors found: 1. Resource with id [StateMachine] is invalid. 'DefinitionUri' is not a valid S3 Uri of the form 's3://bucket/key' with optional versionId query parameter.

I've tried flipping slash direction and prefixing with file:// and file:/// just in case it wasn't recognizing the relative path, to no effect.