Clojure - CI/CD, Delivery, Deploy, DevOps

This action runs Leiningen which automates Clojure projects. It offers various project-related tasks and can: fetch dependencies for your project, run tests, run a fully-configured REPL, compile Java sources (if any), run the project (if the project isn't a library), generate a maven-style 'pom' file for the project for interop, compile and package projects for deployment, publish libraries to repositories such as Clojars, run custom automation tasks written in Clojure (leiningen plug-ins)

This action launches a Docker container using the official Clojure image. The container runs lein test and lein uberjar commands by default. Once the commands stop running, the container is terminated.

It uses the pipeline's filesystem as its working directory to which generated files are saved.

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

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.

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

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

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

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

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