@dronedeploy/dronedeploy-cli

serverless-dronedeploy

The DroneDeploy provider implementaion for the Serverless Framework.

Prerequisites

1. Create a DroneDeploy account

2. Become a DroneDeploy developer (see account settings on the DroneDeploy site)

3. Obtain a DroneDeploy developer API key

   Contact [e-mail] and ask for a developer API key

4. Take a look at our example apps

Quick start

1. Install the Serverless Framework

    npm install -g serverless
   

2. Create new service with the IFTTT application template

    serverless create --name test-service --template-url "https://github.com/dronedeploy/app-examples/tree/master/IFTTT"
   

   If you have the template repository already cloned locally use this command to create service

    serverless create --name test-service --template-path "<path to app-examples>/IFTTT"
   

3. Install dependencies

    cd test-service
    npm install
   

4. Sign in to DroneDeploy with your api key

    serverless config dronedeploy-credentials --provider=dronedeploy --key=<YOUR API KEY>
   

5. Update serverless.yml with your app's id or create new app with

    serverless deploy app --name "my app name"
   

   This will automatically insert new app id into the configuration file.

6. Modify serverless.yml and index.js according to your needs.

7. Deploy all your functions

    serverless deploy
   

   or deploy a single selected function

    serverless deploy --function <function name>
   

DroneDeploy serverless.yml

Functions configuration

Functions deployment via DroneDeploy provider requires additional fields in serverless.yml file. Typical structure of functions block should look like this:

app: my-app-id
functions:
  helloWorld:
    handler: helloWorld

where the top level app field should point to your DroneDeploy app's id and key mapping for the function should be a unique string among your deployed functions for the app.

Additionally, you can pass a timeout(min: 30s, max: 540s) field. By default, timeout = 60s.

Configuration with functions sub-folders

Often, it is useful to organize multiple functions into sub-folders to keep the directory structure clean. The configuration can support this, while still keeping the serverless.yml at the top-level folder. When this is done, a path to the function(s) must be specified in serverless.yml.

Extending the snippet above, if the helloWorld function were located in a sub-folder functions/hello, the function configuration would look like this:

app: my-app-id
functions:
  helloWorld:
    handlerPath: functions/hello
    handler: helloWorld

Datastore configuration

DroneDeploy functions can make use of SQL style tables via the Datastore API. These tables can be defined in serverless.yml to make setup and configuration very easy.

This is done by adding a resources section to a function definition and then defining the tables and columns needed.

For example, and OAuth function might want to store the token data in order to determine access without making a new authorization request every time.

app: my-app-id
functions:
  oauth:
    handlerPath: function/oauth
    handler: oauth
    resources:
      tables:
        token-table:
          description: table to store token data
          columns:
            - name: accessToken
              type: Text
              encrypted: true
              length: 255
              description: Holds the OAuth access token
            - name: expiresAt
              type: DateTime
              description: The date and time that the token expires
            - name: refreshToken
              type: Text
              encrypted: true
              length: 255
              description: Holds the OAuth refresh token

Tables common to all defined functions can be defined by placing the resources property with the table definitions at the root level in serverless.yml (same level as the functions property):

app: my-app-id
functions:
  ...
resources:
  tables:
    table-1-name:
      ...
    table-2-name:
      ...

Valid Datastore column types include:

• Integer
• Float
• Date
• DateTime
• Email
• Text

For Text column types, two additional properties are available:

• encrypted: Encrypts if the column data if true
• length: Length of text allowed in the column, defaults to 255

Triggers configuration

DroneDeploy Functions can take action based on different events that occur in the DroneDeploy platform. These are called Triggers. For example, if you want a function to run once an Export operation has finished, a Trigger can be configured for Export Complete.

The following is an example of how to configure a trigger for a particular function:

app: my-app-id
functions:
  my-example:
    handlerPath: functions/example
    handler: exportComplete
    events:
      - trigger:
          object-type: Export
          type: complete

Multiple triggers may also be configured for a single function if desired. This can be done with the following syntax:

app: my-app-id
functions:
  my-example:
    handlerPath: functions/example
    handler: processComplete
    events:
      - trigger:
          object-type: Export
          type: complete
      - trigger:
          object-type: MapPlan
          type: complete

The following Event Object Types and Event Types are currently supported by the DroneDeploy platform:

Event Object Type (Event Type):

• Export (complete)
• MapPlan (complete)

How to use DroneDeploy Triggers

As we are currently in Beta release and things are subject to change, for now, in order to have your function execute on the defined trigger, you MUST define a handler in your function code.

The handler is for the __ddfunctiontrigger route, and when called by the DroneDeploy platform, should execute the desired code in response to the event.

An example of this can be found in the code for the IFTTT app as seen in our Getting Started Guide

DroneDeploy help commands

Get help for all available commands:

sls help

Get help for specific command:

sls <command> --help

Contributing

Contributions are welcome! Please make a pull request on this repository.

License

MIT

See LICENSE