Custom actions

On top of the default action roster, users can define their own actions and use them in their pipelines. Once configured, custom actions are available across the whole workspace in the Popular / Custom sections of the action list.

Configuration rules

  1. Custom actions are defined as YAML in the project repository.
  2. The actions can be stored in two places:
    a. in the root directory (single action).
    b. in the .buddy/actions directory, with each action in its own subdirectory (multiple actions)
  3. The repository should contain:
    a. action configuration – action.yml or action.yaml b. action icon (optional) – action.jpg, action.jpeg, action.svg, or action.ico c. description (optional) –
  4. The name of the action must be unique throughout the whole workspace. If the name is not unique, a parsing error will appear.
  5. The repository is scanned for new actions:
    a. on every push to the default branch in the repository. The newly added actions are labeled with the 'latest' tag.
    b. on every tag push to the repository. The newly added actions are labeled with the same tag as the push.
  6. The parsing logs for custom actions are located in the push event details.


name: "My_Action"
    required: true
    type: PASSWORD
    required: true
  - echo $user@$ip -p $password
docker_image_name: "node"
docker_image_tag: "16"

YAML paramaters for Custom Actions

The ID of the action in the YAML definition. 40 chars max (a-zA-Z0-9_)
The Docker image from which the container is launched.
The tag of the Docker image from which the container is launched.
execute_commandsThe list of commands run in the container.
shellThe type of the command shell. Default: bash
titleThe title of the action displayed on the action tile and the action adding screen. 40 chars max.
categoryThe category of the action. 100 chars max.
inputsThe list of inputs displayed on the action view.
tabsThe list of tabs displayed on the action view.
outputDefines the tables of environment variables generated by the action for the duration of the pipeline run.
volume_mappingsThe path preceding the colon is the filesystem path (the folder from the filesystem to be mounted in the container). The path after the colon is the container path (the path in the container, where this filesystem will be located).
working_directoryThe working directory of the action.
cached_dirsThe additional container’s directories that will be cached between executions.

List of input parameters

The ID of the input. Used to create the environment variable in the container. 40 chars max (a-zA-Z0-9_). Must be unique. Must not start with buddy. Case sensitive, i.e. user and User act as two separate inputs.
nameThe name displayed on the label of the input. 100 chars max. If not provided, fetches the value from the ID and replaces underscores _ with spacebars.
typeThe type of the input. Default: TEXT
infoAdds a description with additional information below the input. 200 chars max.
optionsThe options of the input. Required by AUTOSUGGEST and SELECT types.
requiredDefault: false.
maskedDefault: false.
defaultThe optional default value injected to the input.

List of input types

TEXTA one-line text input.
PASSWORDUsed to enter password credentials. Always masked on the front-end.
AUTOCOMPLETESupports autocompletion. Requires Options.
SELECTA selector list. Requires Options.
CHECKBOXA box that can be ticked on and off.
TEXTAREAA multi-line text input.
FILESYSTEM_PATHUsed to select paths in the pipeline filesystem.
COMMANDA multi-line text area styled after build actions.
GITHUB_INTEGRATIONEnables selecting the GitHub integration in the project. Uses the integration ID as the input variable. Generates GITHUB_TOKEN.
AWS_INTEGRATIONEnables selecting the AWS integration in the project. Uses the integration ID as the input variable. Generates AWS_ACCESS KEY and AWS_SECRET_KEY.

Filesystem, WD & additional caching

By default:

  1. No filesystem is mounted.
  2. No extra directories (cached_dirs) are cached.
  3. The working directory remains as defined in the image.

All of the above can be defined by adding the following entries, similar to a build action:

  1. Filesystem: volume_mappings
  2. Additional cache: cached_dirs
  3. Working directory: working_directory (overwrites the directory defined in the image)

Access to filesystem

If volume_mappings is defined, it means it requires access to the filesystem. A corresponding checkbox will appear over the inputs. If no access is given, an error will appear upon adding/editing the action.

Example filesystem mapping

   - /:/app

Using custom actions in YAML

- action: "My action"
  type: "CUSTOM"
  custom_type: "name:tag"

If no tag is provided, latest is applied.

Get Started

Sign up for free and deploy your project in less than 10 minutes.