sam cli verb to list out functions/targets to be built

[rojomisin]

Describe your idea/feature/enhancement

I wish SAM CLI would have a command/verb like sam list or sam local list or sam local functions that would parse directories/functions and list out what is going to be built by sam build

Proposal

whatever part of sam build does, that finds targets in the base directory to build, have that as a separate cli action to be able to see what would be built.

maybe a --dry-run flag for build too

Additional Details

https://github.com/awslabs/aws-sam-cli/blob/af124bc559847f1f687538da7fbc9925783d09f8/samcli/commands/build/build_context.py#L140-L154

[awood45]

What are you using this for - would simply adding a --dry-run flag for sam build cover this?

It's unclear what this is adding, some more context about how you would use this would be helpful.

[ozbillwang]

Something as terraform plan vs terraform apply, plan is a dry run option, and it will show what would be changed, but not really change them

or something as aws cdk synthesize (synth) to synthesizes and prints the CloudFormation template for the specified stack(s)

or cdk diff to compares the specified stack with the deployed stack or a local CloudFormation template

[qingchm]

@rojomisin Hey I'm trying to understand this request here! May I just ask what the main benefit do you see from having a dry run build result that does not actually build? Is it for speed considerations? Thanks!

[ozbillwang]

@qingchm

with option --confirm-changeset when run sam deploy, I can see the report which resources will be modified. But with some unknown reason in SAM CLI, all resources are in modify status.

A sample for reference

when mark a resource is in modify status, it didn't tell me the detail which part of the resource will be changed. It is useless. we don't know the modify is only a tag change, name change, or configuraiton change.

with --dry-run option (if we can help), I'd like to get a report before I deploy the change.

What I need know:

1. what resource will be created
2. what resource will be deleted
3. what will be modified in a resource (with detail of which part , configuration, tag, name, etc, to be changed), such as what's the old name, what's the new name,

with this report, I will be confident to release my change, especially to prod environment.

Share a sample, how terraform plan (dry-run) 's output

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # azurerm_kubernetes_cluster.this will be updated in-place
  ~ resource "azurerm_kubernetes_cluster" "this" {
        id                                  = "/subscriptions/xxxx/resourceGroups/staging-aks/providers/Microsoft.ContainerService/managedClusters/staging-aks"
        name                                = "staging-aks"
        tags                                = {
            "Environment" = "staging"
        }
        # (22 unchanged attributes hidden)

      ~ default_node_pool {
            name                         = "pool"
          ~ node_count                   = 2 -> 1
            tags                         = {}
            # (19 unchanged attributes hidden)
        }

        # (4 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

so only the change is marked (marked with ~) in that resource , it is a change on node_count, and when I review the change in production release, I will easily let it go

In AWS CDK, it has similar function with sub-command cdk synth, not that good, but better than sam deploy with --confirm-changeset