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
- Find all active
Build instances across all Environments for a given Service
- Fetch all
Function and Asset Resources
- Fetch all
FunctionVersion and AssetVersion instances given the respective Functions and Assets
- Remove each
FunctionVersion and AssetVersion that is not referenced in an active Build
- 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.
Version 1.x of
twilio-runat 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
Buildinstances across allEnvironmentsfor a givenServiceFunctionandAssetResourcesFunctionVersionandAssetVersioninstances given the respectiveFunctionsandAssetsFunctionVersionandAssetVersionthat is not referenced in an activeBuildFunctionandAssetResources that don't have an activeFunctionVersionorAssetVersionrespectively.Considerations
Since this is a very destructive action we should provide a
--dry-runoption 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-runis not specified. To be friendly to CI/CD we should then also provide a--yesflag as well as respect the--forceflag.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 upPossible Additional Features
#310 is asking for a
removefunctionality 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-servicewhich will delete the entire specified service as well as--delete-environmentwhich 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-sidor--environmentas 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:serviceandtwilio 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 betwilio serverless:cleanup:unusedinstead.Option 3
We have a remove command as a dedicated separate command. This could lead to confusion as mentioned above.