Parameters and Secrets

Parameters are name-value pairs, defined by a user or provided by Automation. The main goal of parameters is to pass various data to your jobs. For example, this might be a Docker image name, a URL, a command-line argument, etc. Or it can be an access token or a password. Such sensitive parameters are called secrets.

Use parameters in jobs

To get a parameter in a job, specify its name in a string inside double curly braces: "{{ my-param }}". You can do this in any string inside any DSL block excluding startOn, git, and kotlinScript.

If your script contains strings with curly braces that are not used for parameters, you should escape them: \\{{ ... }} and/or {{ ... \\}}.

For example, this is how you can reference project parameters:

job("Use job parameters") {
    container("ubuntu") {
        // pass parameters as environment variables
        env["MY_PARAM"] = "{{ project:my-param }}"

        shellScript {
            content = """
                # or use parameters in your shell scripts directly
                echo "My param is: {{ project:my-param }}
            """
        }
    }
}

You can also define parameters right in a job using the job.parameters.text block.

job("Parameterized build") {
    // Users will be able to redefine these parameters in custom job run.
    // See the 'Customize job run' section
    parameters {
        text("build-image", value = "amazoncorretto:17-alpine3.15")
        text("build-command", value = "build --no-configuration-cache")
    }

    container("{{ build-image }}") {
        shellScript {
            content = "./gradlew {{ build-command }}"
        }
    }
}

Use secrets in jobs

You can reference secrets the same way as you can reference parameters, but in a limited number of places. Learn more

job("Use job secrets") {
    container("ubuntu") {
        // pass parameter as environment variable
        env["MY_SECRET"] = "{{ project:my-secret }}"

        shellScript {
            content = """
                if [ ${'$'}MY_SECRET != "1234" ]; then
                    echo "Wrong secret!"
                fi
            """
        }
    }
}

You can also save secrets in files. For example, this is how you can provide an SSH key:

job("SSH auth") {
    parameters {
        // 'private-ssh-key' secret must be created in the project
        secret("private-key", "{{ project:private-ssh-key }}")
    }

    // this could be a 'container' step as well
    host {
        // First put the ssh file to the [[[default file repository|https://www.jetbrains.com.cn/en-us/help/space/store-build-artifacts.html#default-file-repository]]]
        // Then you can get it using 'FileSource.Text'
        fileInput {
            source = FileSource.Text("{{ private-key }}")
            localPath = "/root/.ssh/id_rsa"
        }

        // here goes the rest of the script
    }
}

Use parameters and secrets in kotlinScript

To get parameters inside the kotlinScript blocks, use one of the options:

Environment variables
The parameters API

job("Use parameter in kotlinScript") {
    parameters {
        text("my-param", value = "ABC123")
    }

    container(displayName = "Get param value from env variable", image = "amazoncorretto:17-alpine") {
        env["MY_PARAM"] = "{{ my-param }}"

        kotlinScript { api ->
            val myParam = System.getenv("MY_PARAM")
            println(
                """
                    Get my-param value from env var - $myParam
                """
            )
            // Output:
            // Get my-param value from env var - ABC123
        }
    }
}

Project-wide parameters and secrets

Project parameters are available inside any Automation job within a project. There are two types of project parameters:

Plain text parameters – typically, these are parameters frequently used throughout your Automation scripts. For example, a URL of an external service.
Secrets – parameters stored in the AES-encrypted format. For example, a password or an access token to an external service. Automation hides secret values in job logs for security purposes.
Once you delete a secret from a project, it is instantly deleted from the storage (if there are running jobs that use the secret, it will be deleted once the jobs finish running).

To define project secrets and parameters

Open the desired project.
On the project sidebar menu, choose Settings, then Secrets and Parameters.
Click Create and choose Secret or Parameter.
Specify
- Key: a parameter name. You will use this name to reference this parameter in your scripts.
- Value: a parameter value.
Limitations:
- Secrets and parameters exist only in the scope of a particular project. So, if you create a secret or a parameter in one project, you cannot use them in other projects.
- Keys of secrets and parameters must be unique within a project. A secret and a parameter with the same key are also not allowed.
- A key must be no longer than 128 characters and can only contain alphanumeric characters ([a-z], [A-Z], [0-9]), dashes (-), or underscores (_).
- Max secret's or parameter's value size is 30KB. Note that the max total size of all container arguments, environment variables, secrets, and parameters is also limited by 30KB. For example, if you provide a secret of 30KB and an argument of 1KB to a step, the step will fail.

To use project secrets and parameters

Follow the rules:
- To get a project parameter or secret, use its key preceded with the project: prefix: "{{ project:param-key }}".
- You can get secrets only inside the job.parameters, job.container.env, job.container.shellScript.args, and job.container.args blocks (same refers to all corresponding job.host blocks).
For example:
job("Use project params") { // E.g., a parameter and a secret // 'bintray-repo-url' and 'bintray-repo-password' // exist in the project settings parameters { // you can assign project secrets and params to configured params text("url", value = "{{ project:bintray-repo-url }}") secret("password", value = "{{ project:bintray-repo-password }}") } // Get project parameter values in a shell script container(displayName = "Print param value shell", image = "ubuntu") { env["URL"] = "{{ project:bintray-repo-url }}" // The only way to get a secret in a shell script is an env variable env["PSWRD"] = "{{ project:bintray-repo-password }}" shellScript { content = """ echo "Url from conf param - {{ url }}" echo "Url from env var - ${'$'}URL" echo "Password from env var - ${'$'}PSWRD" echo "Url from project param directly - {{ project:bintray-repo-url }}" # It's not possible to directly reference secrets from a shell script. # The next commented lines would fail. # echo "Password from conf param - {{ password }}" # echo "Password from project param - {{ project:bintray-repo-password }}" """ // Output: // Url from conf param - http://example.com // Url from env var - http://example.com // Password from env var - ***** // Url from project param directly - http://example.com } } // Get project parameter values in a Kotlin script container(displayName = "Print param value kotlin", image = "amazoncorretto:17-alpine") { env["URL"] = "{{ project:bintray-repo-url }}" env["PSWRD"] = "{{ project:bintray-repo-password }}" kotlinScript { api -> println("Url from env var - " + System.getenv("URL")) println("Url from API - " + api.parameters["url"]) println("Password from env var" + System.getenv("PSWRD")) // An advanced use case is the Ref class that holds a // reference to a secret or a parameter: // Ref("project:my-param").toString() == "{{ project:my-param }} // See the example below api.secrets["service-password"] = Ref("project:bintray-repo-password") println("Password from Ref" + api.secrets["service-password"]) // Output: // Url from env var - http://example.com // Url from env API - http://example.com // Password from env var - ***** // Password from Ref - ***** } } }
To see in which jobs a particular secret or parameter is used, open Secrets and Parameters in project settings and click Show usages next to the desired secret or parameter.

Migrate from legacy secrets and parameters

Earlier, it was possible to use the Secrets and Params functions for getting values of project secrets and parameters. These functions are deprecated and will be removed in the future. Therefore, if your Automation scripts use the Secrets or Params functions, we strongly recommend that you replace them with the job.parameters.secret and job.parameters.text blocks.

Legacy script

job("Legacy way to use secrets and params") {
    container(displayName = "Show pwd", image = "ubuntu") {
        env["URL"] = Params("bintray-repo-url")
        env["PSWRD"] = Secrets("bintray-repo-password")

        shellScript {
            content = """
                echo My password for ${'$'}URL
                echo is  ${'$'}PSWRD
            """
        }
    }
}

Replace with

job("New way to use secrets and params") {
    parameters {
        text("url", "{{ project:bintray-repo-url }}")
        secret("password", "{{ project:bintray-repo-password }}")
    }

    container(displayName = "Show pwd", image = "ubuntu") {
        env["URL"] = "{{ url }}"
        env["PSWRD"] = "{{ password }}"

        shellScript {
            content = """
                echo My password for ${'$'}URL
                echo is ${'$'}PSWRD
            """
        }
    }
}

Customize jobs with Custom Run

Users can change the default parameter value before running the script. To run a job with customized parameters, they must use the Custom Run option.

The job.parameters.text function lets you define various types of customizable parameters. The table below shows the possible options and their representation in the Custom Run window.

// Simple text parameter with optional description
text("text-param", value = "default-value", description = "This is a text param")

// Text parameter with no default value. The job will fail
// if a user doesn't specify its value before a custom run
text("param-no-default")

// Multiline text parameter
text("param-multiline", value = "default-value", multiline = true)

// Text parameter that doesn't allow changing its default value
text("param-no-override", value = "non-overridable-value", allowCustomRunOverride = false)

// Drop-down list of values
text("param-options", value = "two") {
    options("one", "two", "three")
}

// List with multiple value choice
text("param-options-multiple-choice", value = "two") {
    options("one", "two", "three") {
        allowMultiple = true
        // optionally, you can specify how the values must be separated
        valueSeparator = ","
    }
}

// Project secret
secret("token", value = "{{ project:auth-token }}", description = "Auth token")

For example, this is how a customizable deployment script may look like:

job("Deploy (custom run)") { startOn {} // disable automatic git push trigger // During a custom run, a user can choose between 'dev' and 'prod' values parameters { text("env", value = "dev") { options("dev", "prod") } } host(displayName = "Setup parameters") { kotlinScript { api -> val env = api.parameters["env"] when (env) { "dev" -> { api.parameters["target-url"] = "my-app.dev.com" // You can use the 'Ref' class to reference a parameter in 'kotlinScript' api.secrets["deploy-token"] = Ref("project:dev-deploy-token") } "prod" -> { api.parameters["target-url"] = "my-app.com" api.secrets["deploy-token"] = Ref("project:prod-deploy-token") } } } } host(displayName = "Deploying to {{ target-url }}") { env["TOKEN"] = "{{ deploy-token }}" shellScript { content = """ # do deploy.. """ } } }

Pass parameters between steps

Sometimes it is necessary to pass execution context (e.g., script run results) from one Automation step to another. To create a parameter or a secret from within a step, you should use the parameters API. The API is available only inside the kotlinScript blocks: the container that runs the step must include JRE/JDK 11 or later.

job("Reuse params") {
    // create a parameter
    container(displayName = "Set param", image = "amazoncorretto:17-alpine") {
        kotlinScript { api ->
            api.parameters["myName"] = "Anna"
            // to delete a parameter, use api.parameters().remove(key: String)
        }
    }

    // get parameter value in a shell script
    container(displayName = "Get param shell", image = "ubuntu") {
        shellScript {
            content = """
                echo Hi {{ myName }}!
            """
        }
        // Output:
        // Hi Anna!
    }

    // get parameter value in Kotlin code
    container(displayName = "Get param kotlin", image = "amazoncorretto:17-alpine") {
        kotlinScript { api ->
            println("Hi ${api.parameters["myName"]}!")
        }
        // Output:
        // Hi Anna!
    }
}

For example, you can use this feature to run a step in an image built in the previous step:

job("Reuse created image") {
    // run step on a self-hosted or cloud worker
    host(displayName = "Generate an image tag") {
        // use kotlinScript blocks for usage of parameters
        kotlinScript { api ->
            api.parameters["imageTag"] = api.gitRevision()
        }
    }

    host(displayName = "Publish image") {
        // publish image to Space Packages registry
        dockerBuildPush {
            push = true
            tags {
                +"{{ imageTag }}"
            }
        }
    }

    // use the newly-built image to run a step
    container(image = "registry.mycompany.jetbrains.space/p/projectName/containerRepo/myImage:{{ imageTag }}") {
        // ...
    }
}

Unlike container steps, inside a host step, you can run a number of subsequent scripts (i.e., shellScript and kotlinScript blocks). But there is a limitation: parameters defined within a script will not be accessible in subsequent scripts within the same host step. For example, the following job will fail:

job("Parameter access with error") {
    host(displayName = "Generate and publish image with tag") {
        kotlinScript { api ->
            api.parameters["imageTag"] = api.gitRevision() // Parameter initialized
        }

        dockerBuildPush {
            push = true
            tags {
                +"{{ imageTag }}"
                // Error 'Failed to start "Generate and publish image with tag": Failed to resolve parameters: [imageTag]'
                // To fix this, move the `dockerBuildPush` block  into a separate `host` step
            }
        }
    }
}

Fallback values for parameters

Sometimes, a parameter value might be missing during a job run: The parameter may not exist in the current context or may resolve to an empty string. For example, when creating a job that normally runs on a merge request, you might reference the review number like {{ run:review.id }}. However, if you run the job manually or with another trigger, the review ID value will be missing, and the job will fail. To prevent this, specify a fallback value for the parameter: {{ run:review.id ?: 'no-review'}}. The no-review fallback value will be used instead if the review ID is missing.

The syntax for specifying fallback values is {{ parameter-name ?: <fallback> }}. Here fallback is a template expression that lets you reference any sequence of fallback parameters or values like {{ param1 ?: param2 ?: 'If no params 1 and 2, this string will be the value' }}. For example:

job("Deploy") { // Users can explicitly specify release-version during Custom Run parameters { text("release-version", value = "") } container(image = "ubuntu") { shellScript { // If release-version is not specified, use the commit ID, otherwise use 'unknown-version' // If the job is triggered by a user, use the user ID, otherwise use 'anonymous' content = """ echo "Version: {{ release-version ?: run:git-checkout.commit ?: 'unknown-version' }}" >> manifest.txt echo "Author: {{ run:trigger.manual.user.id ?: 'anonymous' }}" >> manifest.txt echo Here goes the deployment script... """ } } }

In kotlinScript, you can use the native Kotlin check for nullability:

val paramWithFallback = api.parameters["my-param"] ?: "fallback value"

Vault parameters

In addition to its own secret storage, Space also supports external HashiCorp Vault storage. Once you configure a connection to a Vault server, you can use variables from the storage the same way you use project parameters.

Prerequisites: You have a working Vault server with a configured AppRole. The server stores secrets required by the build script.

To configure connection to a Vault server

Open the desired project.
On the project sidebar menu, choose Settings, then Vault Connections.
Click New connection and specify a connection Name and other settings:
- Vault URL: a URL of the Vault server in the https://vaultserver:port format.
- AppRole ID and AppRole Secret ID: credentials used by Space to log in to the Vault server.
- Parameters namespace: (optional) an additional connection identifier. If a project has multiple Vault connections, Parameters namespace lets you specify which connection must be used to resolve a particular parameter.
- Vault namespace: (optional) a Vault namespace that is used in multi-tenant Vault configurations.
Click Test connection and if connection is successfull, click Create.

To create a Vault parameter

Open the desired project.
On the project sidebar menu, choose Settings, then Secrets and Parameters.
Click Create and choose Vault parameter.
Specify
- Key: a variable name. You will use this name to reference this variable in your scripts.
- Path: a Vault secret path in the Key/Value v1 or v2 secrets engine format. For example, /aws/sts/mysecret.
- Field: (optional) a field name. If a secret has multiple fields, specify the field which value you want to get in an Automation job. If a secret has multiple fields, but you don't specify a field name, Automation will try to get a field named value.
- Namespace: (optional) an identifier of the Vault connection that must resolve the parameter. The Namespace must match the parameters namespace specified for the Vault connection.
Click Save.

To use Vault parameters in a job

Follow the rules:
- To get a project parameter or secret, use the vault:namespace:/secret_path/field_name format. For example:
  - vault:/secret/password: get a value of the secret that has only one field named password.
  - vault:/secret/credentials!/password: get a value of the password field of the /secret/credentials! secret.
  - vault:/secret/json!/store.books[0].category: get a value corresponding to the JsonPath search query (dot notation) in the /secret/json secret stored as a JSON object.
  - vault:/secret/json!/['store'].['books'][0].['category']: get a value corresponding to the JsonPath search query (bracket notation) in the /secret/json secret stored as a JSON object.
  - vault:test:/secret/credentials!/password: get a value of the password field of the /secret/credentials secret using the Vault connection with the test parameters namespace.
- You can get Vault parameters only inside the job.parameters, job.container.env, job.container.shellScript.args, and job.container.args blocks (same refers to all corresponding job.host blocks).
For example:
job("Build") { // reference `username` field of the `/secret/data/credentials!` secret // using the parameters block parameters { secret("username", "{{ vault:secret/data/credentials!/username }}") } container("ubuntu:latest") { // get Vault parameter directly env["PSWRD"] = "{{ vault:/secret/data/credentials!/password }}" // get Vault parameter from defined parameter env["USERNAME"] = "{{ username }}" shellScript { content = """ echo "Username from env var - ${'$'}USERNAME" echo "Password from env var - ${'$'}PSWRD" # It's not possible to directly reference secrets from a shell script. # The next commented lines would fail. # echo "Username from conf param - {{ username }}" """ } } }
To see in which jobs a particular Vault parameter is used, open Secrets and Parameters in project settings and click Show usages next to the desired parameter.

View parameter values after a job run

Navigate to the project.
On the sidebar menu, choose Jobs.
Select a job.
To view all parameters in a job, open the Parameters tab.
To view parameters in a particular step, open the Steps tab, choose a particular step, and open its Parameters tab.

Provided parameters reference

Automation provides a number of predefined parameters which you can use in your build scripts, e.g., a job run number, a Git branch name and commit ID, a URL of your Space instance, and so on.

There are several ways to get the value of a provided parameter (some of these ways may not be available for certain variables):

Use a predefined parameter name, e.g., "{{ run:number }}". Doesn't work in kotlinScript.
Use a predefined environment variable, e.g. $JB_SPACE_EXECUTION_NUMBER.
Inside a kotlinScript block:
- Use an API method that returns the required variable value, e.g., api.executionNumber(). The corresponding API methods always return String values.
- Use the parameters API to get values by parameter names, e.g., api.parameters["run:number"].

For example:

job("Use configured parameter") { parameters { // assign a provided param to a configured param text("run-number-param", value = "{{ run:number }}") } container(displayName = "Print provided param value shell", image = "ubuntu") { shellScript { content = """ echo "Run number from env var - ${'$'}JB_SPACE_EXECUTION_NUMBER" echo "Run number from provided param - {{ run:number }}" echo "Run number from job param - {{ run-number-param }}" """ } // Output: // Run number from env var - 1 // Run number from provided param - 1 // Run number from job param - 1 } container(displayName = "Print provided param value kotlin", image = "amazoncorretto:17-alpine") { kotlinScript { api -> println("Run number from env var - " + System.getenv("JB_SPACE_EXECUTION_NUMBER")) println("Run number from API - " + api.executionNumber()) println("Run number from parameters API - " + api.parameters["run-number-param"]) } // Output: // Run number from env var - 1 // Run number from API - 1 // Run number from parameters API - 1 } }

Predefined name	Description
—	The URL of your JetBrains Space instance. For example: `mycompany.jetbrains.space` Predefined env var: `JB_SPACE_API_URL` `kotlinScript` API method: `spaceUrl()`
`{{run:project.id}}`	The ID of the current project. Predefined env var: `JB_SPACE_PROJECT_ID` `kotlinScript` API method: `projectId()`
`{{run:project_key}}`	The key of the current project. Predefined env var: `JB_SPACE_PROJECT_KEY` `kotlinScript` API method: `projectKey()`
`{{run:file-caches.default-repository}}`	The name of the default cache repository.
—	Temporary OAuth 2.0 access token issued to the current script. The script can use it to authorize in various Space modules. For example, you can use it to authorize the script in a Packages repository in order to publish build artifacts. Predefined env var: `JB_SPACE_CLIENT_TOKEN` `kotlinScript` API method: `spaceClientToken()`
—	As an alternative to an access token, the script can authorize with temporary OAuth 2.0 credentials. Predefined env vars: `JB_SPACE_CLIENT_ID`, `JB_SPACE_CLIENT_SECRET` `kotlinScript` API methods: `spaceClientId()`, `spaceClientSecret()`
`{{run:git-checkout.commit}}`	The current Git commit ID. Predefined env var: `JB_SPACE_GIT_REVISION` `kotlinScript` API method: `gitRevision()`
`{{run:git-checkout.ref}}`	The current Git branch. Predefined env var: `JB_SPACE_GIT_BRANCH` `kotlinScript` API method: `gitBranch()`
`{{run:git-checkout.repositories}}`	A comma-separated list of the checked-out repositories: The Git repository with the currently running `.space.kts` file. All additional repositories. Predefined env var: `JB_SPACE_GIT_REPOSITORY_NAME` `kotlinScript` API method: `gitRepositoryName()`
`{{run:trigger.type}}`	The trigger used to initiate job run. Possible values: `manual`, `git-push`, `schedule`, `git-branch-deleted`, `code-review-opened`, `code-review-closed`, `safe-merge`.
`{{run:trigger.manual.user.id}}`	The ID of the user who triggered job run. Relevant only if the job was run manually by a Space user.
`{{run:trigger.manual.application.id}}`	The ID of the application that triggered job run. Relevant only if the job was run by an HTTP API call from a registered application.
`{{run:trigger.safe-merge.user.id}}`	The ID of the user who triggered safe-merge run. Relevant only if the safe-merge job was run manually by a Space user.
`{{run:trigger.manual.git-checkout.ref}}`	The current Git branch. Relevant only if a user have chosen a particular commit during custom run.
`{{run:trigger.manual.git-checkout.commit}}`	The current Git commit ID. Relevant only if a user have chosen a particular commit during custom run.
`{{run:trigger.git-push.commit}}`	The ID of the commit that triggered job run. Relevant only if the gitPush trigger is enabled.
`{{run:trigger.git-push.commit-before}}`	The ID of the commit that ref was pointing to before this push. Relevant only if the gitPush trigger is enabled.
`{{run:trigger.git-push.ref}}`	The branch which triggered job run. Relevant only if the gitPush trigger is enabled.
`{{run:trigger.git-push.repository}}`	The repository which triggered job run. Relevant only if the gitPush trigger is enabled.
`{{run:trigger.git-branch-deleted.refs}}`	The list of branches/tags that were deleted. Relevant only if the gitBranchDeleted trigger is enabled. A comma is used as a separator, e.g., `refs/heads/branch1,refs/tags/v1-dev`.
`{{run:trigger.code-review-opened.review.id}}`, `{{run:trigger.code-review-closed.review.id}}`	The ID of the review that triggered job run. Relevant only if the codeReviewOpened or codeReviewClosed trigger is enabled.
`{{run:trigger.code-review-opened.source.ref}}`, `{{run:trigger.code-review-closed.source.ref}}`	The branch that goes through the code review. Relevant only if the codeReviewOpened or codeReviewClosed trigger is enabled.
`{{run:run:trigger.code-review-opened.source.commit}}`, `{{run:run:trigger.code-review-closed.source.commit}}`	The ID of the commit that goes through the code review. Relevant only if the codeReviewOpened or codeReviewClosed trigger is enabled.
`{{run:trigger.code-review-opened.target.ref}}`, `{{run:trigger.code-review-closed.target.ref}}`	The branch where the changes are supposed to be merged after the code review. Relevant only if the codeReviewOpened or codeReviewClosed trigger is enabled.
`{{run:run:trigger.code-review-opened.target.commit}}`, `{{run:run:trigger.code-review-closed.target.commit}}`	The ID of the commit that is supposed to be merged after the code review. Relevant only if the codeReviewOpened or codeReviewClosed trigger is enabled.
`{{run:review.id}}`,	The ID of the review that triggered job run. Relevant only if the codeReviewOpened, codeReviewClosed, gitPush (within a merge request) manual (from a merge request page) or safeMerge trigger is enabled.
`{{run:review.source.ref}}`,	The branch that goes through the code review. Relevant only if the codeReviewOpened, codeReviewClosed, gitPush (within a merge request) manual (from a merge request) or safeMerge trigger is enabled.
`{{run:review.source.commit}}`,	The ID of the commit that goes through the code review. Relevant only if the codeReviewOpened, codeReviewClosed, gitPush (within a merge request) manual (from a merge request) or safeMerge trigger is enabled.
`{{run:review.target.ref}}`,	The branch where the changes are supposed to be merged after the code review. Relevant only if the codeReviewOpened, codeReviewClosed, gitPush (within a merge request) manual (from a merge request) or safeMerge trigger is enabled.
`{{run:review.target.commit}}`,	The ID of the commit that is supposed to be merged after the code review. Relevant only if the codeReviewOpened, codeReviewClosed, gitPush (within a merge request) manual (from a merge request) or safeMerge trigger is enabled.
`{{run:review.number}}`,	In-project merge request number. Relevant only if the codeReviewOpened, codeReviewClosed, gitPush (within a merge request) manual (from a merge request) or safeMerge trigger is enabled.
`{{run:id}}`	A unique ID of the current run (build). You can use it to refer to a particular build using the Space API. Predefined env var: `JB_SPACE_EXECUTION_ID` `kotlinScript` API method: `executionId()`
`{{run:job.id}}`	A unique ID of the current job.
`{{run:job.repository}}`	The name of the Git repository where the current `.space.kts` is defined.
`{{run:number}}`	The current job run number (build number). For example, you can use it to generate application version number. Learn more Predefined env var: `JB_SPACE_EXECUTION_NUMBER` `kotlinScript` API method: `executionNumber()`
`{{run:url}}`	A link to the current job execution. Predefined env var: `JB_SPACE_EXECUTION_URL` `kotlinScript` API method: `executionUrl()`
—	The URL of the JetBrains Space instance assigned to the worker. For example, `mycompany.jetbrains.space` Predefined env var: `SPACE_WORKER_SERVERURL`
—	An authorization token issued to the worker. The worker uses it to authenticate in Space. Predefined env var: `SPACE_WORKER_TOKEN`
—	The path to the directory where the script downloads all required data: project sources, file share, and Automation-specific data. Predefined env var: `SPACE_WORKER_DATADIR`
—	A host name of the worker. Predefined env var: `SPACE_WORKER_HOSTNAME`
`{{worker:cpu}}`, `{{worker:memory}}`	The system resources available on the host machine that runs the worker agent: CPU cores in mCPU, and RAM in MB. Predefined env vars: `SPACE_WORKER_CPU`, `SPACE_WORKER_MEM`
`{{worker:hostname}}`	The hostname of the worker machine.
`{{worker:os.arch}}`, `{{worker:os.name}}`, `{{worker:os.version}}`	Target CPU architecture of the operating system (OS), OS type, and OS version on the worker.

Last modified: 21 December 2023