Customizing the launcher workflow

By default, the launcher checks if a workflow.yaml file exists in the root of the repository to load a custom workflow. By default, the launcher is configured with different workflows that contain common operations to build and run applications in the supported languages.

Default workflows

The launcher provides default support for Golang, NodeJS, Python and static content repositories. The associated workflows perform the following steps:


  1. Build phase: go build application
  2. Exec phase: execute application


  1. Build phase: npm install
  2. Exec phase: npm start


  1. Build phase: pip install -r requirements.txt if requirements are specified.
  2. Exec phase: python3 application


  1. Exec phase: Start nginx serving provided files

Workflow structure

A workflow allows us to define a series of steps to be able to deploy an application hosted in a Git repository with additional metadata to be able to automatically determine other aspects such as if the application needs to be exposed.

The basic workflow structure is represented in the following example:

# Version of the workflow specification
version: 0
# Application metadata. This is only processed when the application is launched through the Deploy > Deploy from Git operation. This information is ignored when using a launcher manually.
  name: My application # (optional)
  version: 1.20 # (optional)
  language: golang:1.17 # (optional)
  # (Optional) Define the ports of the running application and whether it needs to be exposed through an endpoint.
  - port: 80 # Port
    service: true # Set to true to create a service to accept incoming requests from other components or applications.
    ingress: true # Set to true to create a public endpoint for the target port.
    ingressPath: / # Path to serve in the ingress.
# Different phases of the workflow.
# pull-code
# pre-build
# build
# pre-exec
    - cmd: cat
      args: ["README"]
    - cmd: "/"
      args: ["nginx","-g", "daemon off;"]

Once the launcher clones the repository, it will process the different phases sequentially stopping if any of them fails.

Supported Phases:

  • pull-code
  • pre-build
  • build
  • pre-exec
  • exec

Merging workflows

The steps specified in any custom workflow.yaml file found on the target repository will be merged with the default workflow configured for the target language to facilitate customization without the need to fully write the whole workflow each time.

For example, assuming a python application that requires a new library, but does not set the requirements.txt file, it will be enough to add the following workflow to the repository

    - cmd: pip3 
      args: ["install","lib"] 

Workflow steps

As explained above, a workflow is made up of steps that the launcher will execute in order to deploy the application. The steps are executed sequentially. The execution of the workflow is interrupted when any of these steps fail. According to the order of execution, the steps are: pull-code, pre-build, build, pre-exec and exec

The default workflows have defined the build and exec steps (except for the web launcher which only defines the exec step) although as indicated above and will be explained later, a user can modify these steps according to her needs.

The steps contain commands to execute. The way to define a step is as follows:

step: # pull-code, pre-build, build, pre-exec or exec
    - cmd: <cmd> # (Required) command to execute 
      args: ["arg1","arg2"] # (Optional) command args 
      dir: <base_dir> # (Optional) Base directory to execute the command
      conditions: # (Optional) Set of conditions to be met to executing the step.
        - type: fileExists # type of condition. Only fileExists supported for now.
          value: <target_file> # Condition value
    - cmd: <cmd> # (Required) command to execute 
      args: ["nginx","-g", "daemon off;"] # (Optional) command args