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:
Golang
- Build phase:
go build
application - Exec phase: execute application
NodeJS
- Build phase:
npm install
- Exec phase:
npm start
Python
- Build phase:
pip install -r requirements.txt
if requirements are specified. - Exec phase:
python3
application
Static
- 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.
application:
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.
ports:
- 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
exec:
commands:
- cmd: cat
args: ["README"]
- cmd: "/docker-entrypoint.sh"
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
build:
commands:
- 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
commands:
- 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