Snap-in manifest
The following section is for version 2 of the manifest specification. For the previous version, see Manifest V1.
The snap-in manifest is what the developers write to define a snap-in. The manifest has the following sections:
Version
The version specifies the manifest version. The following documentation is for version 2 of the manifest. In the manifest, specify the following:
Keyrings
Keyrings are secret tokens used to make calls to external systems. They can be categorized either as organization-scoped or user-scoped. Keyrings are specified in the manifest with the following syntax:
For example:
Keyrings defined in the manifest can be provided in the snap-in configuration screens and are made available to the function. The keyring type is used to determine the type of the keyring and restricts selection on the configuration screen to valid types.
Organization keyrings are common to the organization, while user keyrings are set per user. User keyrings are optional, so the developer must correctly handle cases where the keyring isn’t found.
To view the supported connection types, see Keyrings.
Developer keyrings
Developer keyrings are provided by the snap-in version developer. They’re available across all installations and hidden from the installer. Only the secret string type can be used as developer keyrings.
For example:
Select the developer connection while creating snap_in_version
. The DevRev CLI automatically detects such keyrings in the manifest and asks for them:
Developer keyrings can only be created in the UI. They’re of the Snap-in Secret
type.
Event sources
Event sources can be categorized as “organization” level and “user” level. Event sources are specified in the manifest with the following syntax:
Refer to Event sources for a checklist of supported event sources and their corresponding event types.
Refer to the webhook event-request example for a list of supported webhooks:
For example:
Inputs
Inputs are implemented using per-object schemas, which is a customization technique to store custom schemas inline with the object. Each input’s schema maps to a FieldDescriptor. Inputs, like keyrings and event sources, are organization and user scoped. Organization-scoped inputs are set by the admins of the organization and are common across all users. User inputs are set individually.
Inputs are defined as:
Inputs of type timestamp
, date
and array
of booleans
aren’t supported.
Tags
In the manifest, pass the name and description of the tag.
For example:
Commands
In the manifest, you need to specify the command’s name, its namespace, and the surfaces where it can appear, such as comment discussions. It also specifies the UI description, usage hints, and the function to be triggered when the command is invoked.
For commands, the <name, namespace>
pair should be unique across the Org in which it’s installed.
Functions
In the manifest, pass the name and description of the functions.
For functions, you also need to provide the actual JS/TS code behind this function. Refer to the README in the provided template.
Automations
Automation refers to linking events from the event sources to your functions.
Automations are defined as:
For custom event sources, whatever event key you emit from your policy, the event name will be custom:<your event key>
.