New in version 2.3.
- serverless
parameter | required | default | choices | comments |
---|---|---|---|---|
deploy |
no | True | Whether or not to deploy artifacts after building them. When this option is `false` all the functions will be built, but no stack update will be run to send them out. This is mostly useful for generating artifacts to be stored/deployed elsewhere. | |
functions |
no | A list of specific functions to deploy. If this is not provided, all functions in the service will be deployed. | ||
region |
no | us-east-1 | AWS region to deploy the service to | |
service_path |
yes | The path to the root of the Serverless Service to be operated on. | ||
state |
no | present |
|
Goal state of given stage/project |
# Basic deploy of a service - serverless: service_path: '{{ project_dir }}' state: present # Deploy specific functions - serverless: service_path: '{{ project_dir }}' functions: - my_func_one - my_func_two # deploy a project, then pull its resource list back into Ansible - serverless: stage: dev region: us-east-1 service_path: '{{ project_dir }}' register: sls # The cloudformation stack is always named the same as the full service, so the # cloudformation_facts module can get a full list of the stack resources, as # well as stack events and outputs - cloudformation_facts: region: us-east-1 stack_name: '{{ sls.service_name }}' stack_resources: true
Common return values are documented here Return Values, the following are the fields unique to this module:
name | description | returned | type | sample |
---|---|---|---|---|
service_name | Most | always | string | my-fancy-service-dev |
state | Whether the stack for the serverless project is present/absent. | always | string | |
command | Full `serverless` command run by this module, in case you want to re-run the command outside the module. | always | string | serverless deploy --stage production |
Note
This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.
This module is community maintained without core committer oversight.
For more information on what this means please read Module Support
For help in developing on modules, should you be so inclined, please read Community Information & Contributing, Helping Testing PRs and Developing Modules.