Project config file (config.yml)

Most of the configurations for your dapp are available in the project configuration file. 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. Remember that most 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:
  MyBlockchain: #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>
    moduleArgs: #You can't access the args field if the module_args struct isn't defined.
      <module_name>:
        <arg_name>: <value>
  MyBlockchain2: #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)
      MyBlockchain: <BlockchainRID> #Dapp Blockchain RID
      MyBlockchain2: <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
  deprecatedError: false
  quiet: true
  rellVersion: <version>

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 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

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 must 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