Skip to content

Add cleanup command #311

Open
Open
@dkundel

Description

@dkundel

Version 1.x of twilio-run at one point introduced a bug through a downstream dependency that would create additional unnecessary resources upon every deploy if the project had more than 50 Functions or more than 50 Assets.

Twilio runs an automated cleanup job every 30 days that removes unused Functions and Assets both the respective Versions as well as any unused Resources.

Since the same logic can be executed through the public APIs it would be useful to provide customers with the same functionality.

Logic

  1. Find all active Build instances across all Environments for a given Service
  2. Fetch all Function and Asset Resources
  3. Fetch all FunctionVersion and AssetVersion instances given the respective Functions and Assets
  4. Remove each FunctionVersion and AssetVersion that is not referenced in an active Build
  5. Remove all Function and Asset Resources that don't have an active FunctionVersion or AssetVersion respectively.

Considerations

Since this is a very destructive action we should provide a --dry-run option that will perform the same logic but will output all resources that would be deleted without actually deleting them.

Thought: Should we provide a prompt statement asking the user to confirm the deletion if --dry-run is not specified. To be friendly to CI/CD we should then also provide a --yes flag as well as respect the --force flag.

Format

$ twilio serverless:cleanup --help
Removes unused functions and assets from your service.

USAGE
  $ twilio serverless:cleanup

OPTIONS
  -c, --config=config                      Location of the config file. Absolute
                                           path or relative to current working
                                           directory (cwd)

  -l, --log-level=log-level                [default: info] Level of logging
                                           messages.

  -p, --profile=profile                    Shorthand identifier for your
                                           profile.

  -u, --username=username                  A specific API key or account SID to
                                           be used for deployment. Uses fields
                                           in .env otherwise

  --cwd=cwd                                Sets the directory of your existing
                                           Serverless project. Defaults to
                                           current directory

  --password=password                      A specific API secret or auth token
                                           for deployment. Uses fields from .env
                                           otherwise

  --service-sid=service-sid                SID of the Twilio Serverless Service
                                           to clean up

Possible Additional Features

#310 is asking for a remove functionality to delete the service. One option is to have these two commands live side by side but that could be confusing to customers.

An alternative would be to add additional features to this command. The same functionality for example could be useful to delete a specific environment.

Option 1

Specific destructive flags such as --delete-service which will delete the entire specified service as well as --delete-environment which will delete an entire environment as well as perform the regular cleanup specified above.

If we go with this option the question would be if we should explicity require --service-sid or --environment as flags if either of the two --delete-* flags are being used or if we follow the same concept as any other command and try to infer these values.

Option 2

Dedicated subcommands. We could provide twilio serverless:cleanup:service and twilio serverless:cleanup:environment. The benefit would be that it's likely more discoverable than Option 1 but it would also raise the question if the base command should be twilio serverless:cleanup:unused instead.

Option 3

We have a remove command as a dedicated separate command. This could lead to confusion as mentioned above.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions