Haskell

Run commands

• The field supports multiple commands (one per line), piping commands together, or splitting a single command into multiple lines with \ (backslash) at the end of each line
• The action is marked as failed when a command exits with a non-zero value
• Both shell (SH) and Bourne shell (BASH) are supported. If BASH is used, make sure that the selected Docker image has BASH available
• The action supports Environment variables which could be used in build commands (Run tab) and for Cache
• If encrypted ENV VARs are used in build commands (Run tab), their values will be masked in the action logs
• Settable variables with a scope higher than the pipeline (ex: project, workspace) are passing their values between pipelines
• Exit code handling: you can either halt the commands if any throws an error or run the following commands regardless of the result of previous command

Pipeline’s filesystem

• By default, commands are run in the filesystem mounted to the pipeline (working directory)
• A pipeline filesystem contains the fetched Git repository, artifacts generated by build actions, and static files uploaded by the user
• On each pipeline execution, a git pull request is executed and the pipeline's filesystem is populated with the Git repository content
• If one action overwrites a fetched file from the Git repository, all remaining actions will use the overwritten file
• The result of the action execution, like generated files (artifacts), is saved to the pipeline filesystem and can be processed or deployed by another action
• Buddy caches Docker layers between executions and rebuilds only those that have changed
• Everything saved to the default working directory remains in the pipeline filesystem and is available for other actions and between executions
• All files & directories created in the launched container outside the default working directory/pipeline filesystem are lost when the execution ends.

Environment

• You can change the Docker image used by this action to any other image from the selected Docker registry or an image built with Buddy
• If the Latest tag is used, Buddy will pull the newest version of the Docker image from the registry on each execution (provided it exists)
• You can use your own Docker image from the Docker Hub Private and Docker Hub Public, Amazon ECR, Google GCR, or any other private or public Docker repository
• It is also possible to use custom images created with the Build Docker image action in previous steps of the pipeline

Caching

• The Cache tab lets you change the mounting point of the filesystem and the working directory of the executed commands
• If you need to preinstall packages before running your commands, you can put them in the Customize Environment section of the Environment tab. The commands listed there will be executed only once and cached between executions by default
• Commands defined in the Customize Environment section of the Environment tab don’t have access to the pipeline filesystem as it is not yet mounted at the moment of their execution
• All files & directories created outside the default working directory of the launched container are lost when the execution ends. To keep the data between executions, list them in the Additional Cache section of the Cache tab
• The caching options are features unique to Buddy and extremely speed up building, testing & deploying

Variables

• If commands specified on the Run tab change the value of the variable marked as settable on the Environment variables tab, the new value will be passed on to the next actions
• Commands defined in the Customize environment section of the Environment tab do not support Variables
• SSH keys defined in the ENV VARs are added to ~/.ssh directory of the launched action, so they can be used to fetch private dependencies

Services

• You can attach services and databases with a single click in the Services tab
• Supported services: Cassandra, Elastic, MariaDB, Memcached, MongoDB, MySQL, Postgres, RabbitMQ, Redis, Selenium Chrome & Selenium Firefox
• It is possible to create and reuse your own services which are defined by selecting an image, mounting point of the pipeline filesystem, and cache. The services will be automatically linked via Docker Compose and launched with the main container

Conditions

• It is possible to specify conditions under which the action will be executed
• Available conditions: always, on changes in the repository since the last run, on changes in specific paths in the repository, or when a Variable has a specific value
• Error handling: you can either stop the execution, mark action and pipeline as failed or proceed the execution, mark action as warning and jump to the next action