[cli, lambda] skip expensive bundling during "cdk list" and other operations where the stack is not needed

[imtiazmangerah]

Running cdk list on a project that uses custom asset bundling results in the following observed issues:

• The assets are rebuilt using docker which results in a long delay to see the list of stacks, particularly for large projects
• A new bundle is created in .cdk.staging resulting in wasted space
• The console is polluted with output from the build process (see console output below)

NB: I am using aws_lambda_python.PythonFunction

Reproduction Steps

from aws_cdk import core
from aws_cdk import aws_lambda
from aws_cdk.aws_lambda_python import PythonFunction


class SchedulerStack(core.Stack):

    def __init__(self, scope: core.Construct, id: str, **kwargs) -> None:
        super().__init__(scope, id, **kwargs)

        PythonFunction(
            self, f"{id}-TestFunction",
            function_name=f"{id}-TestFunction",
            entry='build/scheduler',
            index='handlers.py',
            handler='handler',
            runtime=aws_lambda.Runtime.PYTHON_3_7,
            timeout=core.Duration.seconds(60),
        )

# partial extract of usage
app = core.App()
scheduler = SchedulerStack(app, f'{APP_NAME}-Scheduler-{stage}', env=env)
app.synth()

What did you expect to happen?

Running cdk list should quickly return the list of stacks in the app, and should have no side effects such as triggering a new build.

What actually happened?

Output

> cdk ls
Bundling asset Starterkit-Scheduler-dev/Starterkit-Scheduler-dev-TestFunction/Code/Stage...
WARNING: The directory '/.cache/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
WARNING: The directory '/.cache/pip' or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Collecting pendulum (from -r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/3e/40/bcf73cf69ffc4d68b80b68b5ce4e5f9d8185170e9fac65a73e247e948ff3/pendulum-2.1.2-cp37-cp37m-manylinux1_x86_64.whl (155kB)
Collecting python-dateutil<3.0,>=2.6 (from pendulum->-r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/d4/70/d60450c3dd48ef87586924207ae8907090de0b306af2bce5d134d78615cb/python_dateutil-2.8.1-py2.py3-none-any.whl (227kB)
Collecting pytzdata>=2020.1 (from pendulum->-r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/e0/4f/4474bda990ee740a020cbc3eb271925ef7daa7c8444240d34ff62c8442a3/pytzdata-2020.1-py2.py3-none-any.whl (489kB)
Collecting six>=1.5 (from python-dateutil<3.0,>=2.6->pendulum->-r requirements.txt (line 1))
  Downloading https://files.pythonhosted.org/packages/ee/ff/48bde5c0f013094d729fe4b0316ba2a24774b3ff1c52d924a8a4cb04078a/six-1.15.0-py2.py3-none-any.whl
Installing collected packages: six, python-dateutil, pytzdata, pendulum
Successfully installed pendulum-2.1.2 python-dateutil-2.8.1 pytzdata-2020.1 six-1.15.0
WARNING: You are using pip version 19.2.3, however version 20.2.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Starterkit-Scheduler-dev

Environment

• CLI Version : 1.57.0 (build 2ccfc50)
• Framework Version: 1.57.0
• Node.js Version: v12.0.0
• OS : Debian 10.5
• Language (Version): Python 3.7.6

Other

---

This is 🐛 Bug Report

[jogold]

@eladb should/could constructs be aware of what triggered their "construction"? There is also the case when doing synth with -e on a specific stack, other stacks could skip bundling.

[eladb]

Generally we stayed away from special casing various CLI commands, but I can see why the heavy lifting done in bundling could be problematic for cdk list and when specific stacks are not required.

I do think we may need to write a short RFC about this to vet this with the team. Is that something you'd like to take? We are actually trying to simplify the RFC format so it really should not be too hard.

Copying @shivlaks who owns the CLI.

[imtiazmangerah]

Could a --no-bundling CLI flag solve the issue for both a list and synth? The way I imagine it being implemented is similar to the --no-staging flag but it would be used to bypass docker bundling.

EDIT: This does not solve the issue of a synth with a -e

[eladb]

We can definitely add a --no-bundling[=stack, stack] option which will accept an optional list of stacks to skip bundling (no stacks implies *) and will default to * for list.

[jogold]

@eladb do you still want to see an RFC for this or can we go for your suggestion:

We can definitely add a --no-bundling[=stack, stack] option which will accept an optional list of stacks to skip bundling (no stacks implies *) and will default to * for list.

[gabsn]

up, we still need this