Space Automation automation Help

Run a Step in a Container

Short overview:

Running a shell script

Using the shellScript block, you can run an arbitrary shell script. This could be a one-liner or a multiline script. The default script interpreter /bin/sh can be changed with interpreter.

For example:

job("run shell script") { container("ubuntu") { shellScript { interpreter = "/bin/bash" content = """ echo Hello echo World! """ } } }

If you want to run an existing script file (e.g., stored in the project repository), you should specify its location. It could be an absolute path, or a path that is relative to workDir.

job("run shell script") { container("ubuntu") { shellScript { location = "./" } } }

Running Kotlin code

As the Automation DSL is based on Kotlin, you can run any Kotlin code inside job steps. In case of a container, you should put your code inside the kotlinScript block. For example:

job("build and publish") { container("gradle:6.1.1-jre11") { kotlinScript { api -> api.gradle("build") try { api.gradle("publish") } catch (ex: Exception) { println("Publishing failed") } } } }

How it works under the hood (with some simplification): Space compiles the script into a .jar file and runs it with a command like java -jar script.jar. This means that the image you use to run the script must include JRE/JDK (version 8 or later).

APIs for working with Space modules and external tools

In the kotlinScript block, you have access to various APIs: Space module APIs and APIs for various external tools (Gradle, dotnet, and others).

job("build and publish") { container("gradle") { kotlinScript { api -> try { api.gradle("build") } catch (ex: Exception) { val recipient = MessageRecipient.Channel(ChatChannel.FromName("CI-channel")) val content = ChatMessage.Text("Build failed"), content) } } } }

In this example, we use api.gradle to run Gradle commands and to access the Chats module. For the full list of APIs, refer to job.container.kotlinScript.

Running a container image command

To run a default image command, provide its arguments in the args array. Note that special characters must be escaped.

For example:

job("Example") { container("alpine") { args("echo", "Hello World!") } }

If you want to override the default image command, you can do this by using entrypoint. In this case, args provide arguments for the entrypoint command. Note that special characters must be escaped.

For example:

job("Example") { container("gradle:latest") { entrypoint("/bin/sh") args("echo", "Hello World!") } }

Build environment

/ ├─── mnt │ ├─── space │ │ ├─── work // project sources │ │ └─── share // file share ...

Before running user jobs, Automation runs a hidden "bootstrap" job that:

  1. creates a disk volume,

  2. clones the project sources from the Git server to the volume,

  3. mounts the volume to the container. By default, the volume is mounted to /mnt/space:

    • You can change the default location with mountDir .

    • The project location is always $mountDir/work. It is also the container's default working directory.

    • The volume also contains $mountDir/share: external storage used for file sharing.

Note that if a job is not supposed to anyhow work with the project code, you can disable cloning the project sources by setting cloneRepository = false . This will reduce the job execution time.

Container resources

Each job can contain not more than 50 "container" steps. Each container has the following resources constraints:

Default MaxMin
CPU 2048 CPU units (2 virtual CPUs) 4096 CPU units 180 CPU units
Memory 7800 MiB 16 GiB

Note that all containers within a job use the same disk volume (it contains the project repository). The default volume size is 5 GB and the maximum allowed size is 30 GB. To specify resources and volume size, you should use resources and volumeSize correspondingly:

job("Example") { // 10 GB volumeSize = 10 container("alpine") { resources { // .5 vCPU cpu = 512 // 2000 MB memory = 2000 } } }
Last modified: 27 July 2020