Skip to main content

Project settings file

Most configurations for your dapp are available in the project configuration file. By default, it's called chromia.yml, but you can name it to something else if there is a need to do so.

Following is an example of such a file. Remember that most attributes have default values and don't need to be configured unless you want to override the default behavior.

blockchains

This section defines the blockchains used in your project. Each blockchain has a unique name, specifying the entry point module, configuration options, block strategies, and module arguments.

Example minimum file:

blockchains:
hello: #Name of the blockchain
module: main #Entrypoint to the project

Example full file:

blockchains:
<blockchain_name_1>:
module: main
moduleArgs:
<name.of.module_1>:
<name_of_argument_1>: x"<value>"
<name_of_argument_2>: x"<value>"
<name.of.module_2>:
<name_of_argument_1>: x"<value>"
<name_of_argument_2>: x"<value>"
config:
<config name>: <value>
test:
modules:
- <name.of.test.module_1>
- <name.of.test.module_2>
moduleArgs:
<name.of.module>:
<name_of_argument_1>: x"<value>"
failOnError: true

<blockchain_name>

Input: string

The name of the individual blockchain you are configuring is a mandatory field that identifies the specific blockchain within the list.

<blockchain>:module

Input: string

Specifies the module responsible for interacting with the chosen blockchain.

<blockchain>:moduleArgs

Input: dict

This field defines the arguments to be passed to the specified module. It's an optional field. However, note that you can't access the args field in the module if the moduleArgs structure isn't defined.

<blockchain>:config

Input: dict

Allows you to specify any specific configuration settings for the chosen blockchain. It's an optional field. Each setting uses a <config name> paired with a corresponding <GTV Value>. See the blockchain configuration topic for more information.

<blockchain>:test

Input: dict

This section defines the tests to be executed for the blockchain. See the test section for more information.

deployments

This section configures deployment targets for your blockchains. Each deployment defines the target blockchain RID, URLs, container ID, and deployed chains with their respective RIDs.

Example:

deployments:
<deployment_name_1>:
brid: x"<BlockchainRid>"
url:
- <TargetURL>
- <TargetURL>
container: <containerIID>
chains:
<blockchain_name_1>: x"<BlockchainRid>" # Name should match field in blockchains. In this case, blockchain_name_1.
<blockchain_name_2>: x"<BlockchainRid>"
<deployment_name_2>:
brid: x"<BlockchainRid>"
url: <TargetURL>
container: <containerIID>

<deployment_name>

Input: string

The deployment target's name acts as a unique identifier for your deployed configuration. It can be any descriptive name to distinguish between different environments or setups.

<deployment>:brid

Input: byte_array (Hexadecimal string representation of a byte_array. For example: x”ABABABA”.)

Defines the Blockchain RID (Referential ID) of the management chain for the target network. For example, x"1212121212121212121212121212121212121212121212121212121212121212".

<deployment>:url

Input: list of strings or string

A list of strings of Target URLs for accessing the deployed application on the specified blockchain network.

Example:

url: https://node1:7740
url:
- https://node1:7740
- https://node2:7740

<deployment>:container

Input: string

Specifies the Container ID of the container.

<deployment>:chains

Input: dict (string to hex-string)

Defines the individual blockchains deployed on this target. The keys of the dict must match a key in blockchains.

Valid example:

blockchains:
my-chain:
module: main
deployments:
network1:
url: http://localhost:7740
brid: x"ABAB"
chains:
my-chain: x"121212"

Invalid example:

blockchains:
my-chain:
module: main
deployments:
network1:
url: http://localhost:7740
brid: x"ABAB"
chains:
my-other-chain: x"121212"

compile

This section configures deployment targets for your blockchains. Each deployment defines the target blockchain RID, URLs, container ID, and deployed chains with their respective RIDs.

Example:

compile:
rellVersion: 0.13.5
source: src
target: build
deprecatedError: false
quiet: true
strictGtvConversion: true

compile:rellVersion

Input: string (semver)

Specifies the Rell version.

compile:source

Input: string

Defines the relative path to the directory containing your dapp source code files.

compile:target

Input: string

Defines the relative path to the directory where the compiled artifacts will be generated.

compile:deprecatedError

Input: boolean

This controls whether the compiler throws errors upon encountering deprecated syntax or features. Setting it to true causes a build failure if deprecated features are used.

compile:quiet

Input: boolean

Decides on the compiler messages during the compilation process. Set it to true if you don't want to see intermediary compilation output.

compile:strictGtvConversion

Input: boolean

This controls the use of strict GTV conversion when parsing operation arguments; it is recommended that you leave this to true (the default). See type conversions for more details.

note

This option is only available from Rell 0.13.9. Before, it behaved as if this option was set to false.

database

This section configures the PostgreSQL database connection settings for your project. It defines the password, username, database name, host, logging behavior for SQL errors, schema name, and database driver.

Example:

database:
password: postchain
username: postchain
database: postchain
host: localhost
logSqlErrors: true
schema: rell_app
driver: org.postgresql.Driver

database:password

Input: string

The password for the database user.

database:username

Input: string

The username for the database.

database:database

Input: string

The name of the database to connect to.

database:host

Input: string

The hostname or IP address of the database server.

database:logSqlErrors

Input: boolean

Specifies whether to log SQL errors encountered during database interaction. If set to true, it enables logging of SQL errors encountered during database interaction. This can be helpful for debugging issues.

database:schema

Input: string

The database schema containing your dapp's tables and data.

database:driver

Input: string

The Java class name for the JDBC driver used to connect to the PostgreSQL database.

warning

Consider storing sensitive information like passwords in secure environments instead of directly in the YAML file.

Database variables

You might want to store PostgreSQL database settings as environment variables instead of saving them in the chromia.yml file for various reasons, such as security.

In that case, you can set values by entering export ENV_VAR_NAME=env_var_value in the terminal or adding the commands to your ~/.bashrc file. For example,

export CHR_DB_URL=URL
export CHR_DB_USER=user
export CHR_DB_PASSWORD='pwd'
export CHR_DB_SCHEMA=app

These values override the values that are present in chromia.yml.

We also support environment variables for string substitution in chromia.yml. It follows the following schema: foo: ${MY_VAR:-default_var}.

test

This section defines the tests to be executed for your project. It lists the test modules, allows specifying arguments for specific modules, and enables test failure termination.

Example:

test:
modules:
- <name.of.test.module_1>
- <name.of.test.module_2>
moduleArgs:
<name.of.module>:
<name_of_argument_1>: x"<value>"
failOnError: true

test:modules

Input: string

List of test modules to be executed. Each module is represented by its filename relative to the test directory.

test:moduleArgs

Input: dict

Allows you to pass arguments to individual test modules.

test:failOnError

Input: boolean

Determines whether the entire test run should fail if any individual test case fails.

tip

Consider using descriptive names for tests and modules for clarity.

Test module arguments

If a method needs arguments, they can be specified in the moduleArgs key. For example, if you have a test query method in a module called arg_test.rell in the test folder, that looks as follows:

@test module;
struct module_args {
value: integer;
}

function test_foo() {
assert_equals(2 + 2, chain_context.args.value);
}

Then the test key would look like this, for that project:

test:
modules:
- test.arg_test
moduleArgs:
test.arg_test:
value: 4
note

You can also add tests to a specific blockchain in your project as follows:

blockchains:
my_chain:
module: main
test:
modules:
- main.test
moduleArgs: ...

moduleArgs overrides the project-level test module with the ones that are defined in the blockchain.

libs

This section defines external libraries used in your project. It specifies the library name, registry URL, path within the repository, optional branch or tag, RID, and insecure download verification option.

Example:

libs:
<library_name>:
registry: <url to git repository>
path: <path to library inside the repository>
tagOrBranch: <value>
rid: x"<value>"
insecure: false

<library_name>

Input: string

List of test modules to be executed. Each module is represented by its filename relative to the test directory.

<lib>:registry

Input: string

Specifies the URL of the Git repository containing the library source code. Ensure the repository holds the relevant library files.

<lib>:path

Input: string

Defines the specific path within the repository where the library files reside.

<lib>:tagOrBranch

Input: string

Allows you to specify a particular branch or tagged version of the Git repository to download. By default, the latest commit on the master branch will be used.

<lib>:rid

Input: byte_array (Hexadecimal string representation of a byte_array. For example: x”ABABABA”.)

The GTV hash of the complete library's Rell files.

<lib>:insecure

Input: boolean

Allows you to bypass the cryptographic hash check against the rid. Setting it to true turns off verification, which is not recommended for production usage as it compromises safety and version control.

docs

This section describes the configuration for generate docs-site.

docs:title

Input: string

Specifies the title of the generated site.

docs:footerMessage

Input: string

Specifies a string to be shown in the footer of the generated site.

docs:customStyleSheets

Input: list of strings

Include any custom style sheets. Use this to override the existing styles to personalize your site.

docs:customAssets

Input: list of strings

Include any files you want to be included in the generated site. The files will be moved to the images folder of the generated site.

docs:additionalContent

Input: list of strings

A list of markdown files that is used to populate the main page and the rell module sections.

Example

my-doc.md
// Name must match the title of the site

# Dapp <My Rell Dapp>

// Content

# Module <module-1>

// Content shown on the start page and module page // Content shown on the module page

## Sub-titles are allowed

// Content

# Module <module-2>

// Content

docs:sourceLink:remoteUrl

Input: string

URL of the source code corresponding to this code base. The URL should include the path to the project's source folder.

Example

https://github.com/my-repo/blob/main/src/

docs:sourceLink:remoteLineSuffix

Input: string

String corresponding to the line suffix used by the Git project as a divider between the URL and the line number. Typically, one of the:

  • Github: "#L"
  • Gitlab: "#L"
  • Bitbucket: "#lines-"

YAML anchors

It's possible to use YAML anchoring, as shown in the example below, where the tests are anchored to the definitions key in the file. Any anchored value must be in the definitions key.

Example:

definitions: #Used for YAML anchors in this file
modules: &test
- test.arithmetic_test
- test.data_test

blockchains:
hello:
module: main
test:
modules: *test

Include another YAML configuration

To include another YAML configuration, you can use the !include tag.

#test.yml
a: 13
b: 15
#chromia.yml
blockchains:
hello:
module: main
test:
modules: !include test.yml

You get:

#chromia.yml
blockchains:
hello:
module: main
test:
modules:
a: 13
b: 15

You can also include a specific tag from another YAML file. For example:

#test.yml
a: 13
b: 15
#chromia.yml
blockchains:
hello:
module: main
test:
modules: !include test.yml#a

You get:

#chromia.yml
blockchains:
hello:
module: main
test:
modules: 13