Project settings file (config.yml)

The project settings file is where most of the configurations for your dapp are available. By default, it's called config.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. Keep in mind that most of the attributes have default values and don't need to be configured unless you want to override the default behavior.

note

These files are taken from Build and run the Hello World dapp with Chromia CLI.

Minimum file

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

Full file

#Blockchains are not default, this is where you add your chains
blockchains:
  hello: #Name of the blockchain
    module: main #Entrypoint to the project
    config: #If you have any specific config settings that you want to include
      <config name>: <GTV Value>
      blockstrategy: #If you have any specific block strategies
        <config tag>: <GTV Value>

  My_Rell_Project2: #This is all that is needed for a working blockchain
    module: main2

deployments:
  devnet1: #Deployment Target name
    brid: x"<BlockchainRID>" #Target Blockchain RID
    url:
      - <TargetURL> #Target URL
      - <TargetURL> #Optional Target URL
    container: <ContainerID> #Container ID
    chains: #All of your deployed chains on this target, important that it is denoted with its genesis brid (Brid that is used on first deployment)
      hello: <BlockchainRID> #Dapp Blockchain RID
      My_Rell_Project2: <BlockchainRID> #Dapp Blockchain RID
  devnet2: #How a target looks before first deployment
    brid: x"<BlockchainRID>" #Target Blockchain RID
    url: <TargetURL> #Target URL
    container: <ContainerID> #Container ID

compile: #The compile attributes are all defaulted as followed
  source: src
  target: build
  gtv: false
  deprecatedError: false
  ide: false
  blockCheck: false
  testLib: false
  hiddenLib: false
  allowDbModificationsInObjectExprs: false
  rellVersion: 0.11.0
  symbolInfoFile: null
  quiet: true

database: #The database attributes are all defaulted as followed
  password: postchain
  username: postchain
  database: postchain
  host: localhost
  logSqlErrors: true
  schema: rell_app
  driver: org.postgresql.Driver

test: #Not default
  modules: #List of the test modules in your project
    - test.arithmetic_test
    - otherFolder.data_test
  moduleArgs:
    test.module_name: #Module that should have a specific argument(s)
      <argument name>: <gtv Value>

Database variables

You might want to store PostgreSQL database settings as environment variables instead of saving them in the config.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 config.yml.

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

Blockchain configuration and block strategy

The documentation of the blockchain configuration and block strategy can be found here.

Test module arguments

If there is a method that 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

YAML anchoring

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

definitions:
  modules: &test
    - test.arithmetic_test
    - test.data_test

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

Including another YAML configuration

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

#test.yml
a: 13
b: 15

#config.yml
blockchains:
  hello:
    module: main
test:
  modules: !include test.yml

You get:

#config.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

#config.yml
blockchains:
  hello:
    module: main
test:
  modules: !include test.yml#a

You get:

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