This cheat sheet provides a detailed overview of the exposed lifecycle events and available commands (and entrypoints) of the Serverless framework, that can be hooked by plugins (internal and external ones). The document is structured by the commands invoked by the user.
Lifecycle events are shown as the globally available outer events (all providers) and sub lifecycle events that are provider specific in the called order. Currently only the AWS provider is shown. If you have information about the other provider, please let me know and I will add the sub lifecycles accordingly.
The current event system can be improved in the future. Only package, deploy and info provide detailed event lifecycles for now, that make the plugin integration much more fine-grained.
Plugins can spawn any command or entrypoint with this.serverless.pluginManager.spawn()
and invoke a sub lifecycle.
-> aws:common:validate:validate
-> aws:common:cleanupTempDir:cleanup
-> aws:package:finalize:mergeCustomProviderResources
-> aws:package:finalize:saveServiceState
-> aws:common:moveArtifactsToPackage:move
-> aws:common:validate:validate
-> aws:common:moveArtifactsToTemp:move
-> aws:deploy:deploy:createStack
-> aws:deploy:deploy:checkForChanges (1.17->)
-> aws:deploy:deploy:uploadArtifacts
-> aws:deploy:deploy:validateTemplate
-> aws:deploy:deploy:updateStack
-> aws:deploy:finalize:cleanup
-> package:function:package
-> aws:common:cleanupTempDir:cleanup
-> aws:info:validate
-> aws:info:gatherData
-> aws:info:displayServiceInfo
-> aws:info:displayApiKeys
-> aws:info:displayEndpoints
-> aws:info:displayFunctions
-> aws:info:displayStackOutputs
The cheat sheet is very useful, thanks!
My major concern is to what extent we are supposed to fiddle with serverless internals. I.e. when is something good / bad practice when done with plugins.
For example, take this practical case: I have created a custom resource that requests ACM certificates. This works fine. However, cloudfront only accepts ACM certificates that have been fully validated (i.e. issued). This means that you can only pass such certificate to cloudfront after it has been validated. Unfortunately, you cannot have a custom resource wait until validation has passed due to the 5 minute timeout of Lambda. The only solution seems to be to create a cloudformation condition like so:
And then have cloudfront only consume the certificate if it is indeed said to be valid:
Now, something has to substitute this string for it to equal
true
orfalse
, depending on whether the certificate is ready to be consumed by cloudfront. I created a plugin that does this. This plugin is then run before thepackage:createDeploymentArtifacts
event. But are these expected practices? Or are there cleaner way to do these sort of things? I think it would be great to add some guidelines in terms of "dos" and "donts" to the developer documentation.