Skip to content

Latest commit

 

History

History
79 lines (55 loc) · 4.08 KB

deploy.md

File metadata and controls

79 lines (55 loc) · 4.08 KB
Raw

Burrow Deploy (Playbooks)

The Burrow deploy toolkit can do a number of things:

  • compile Solidity source files (using solc) and deploy to chain
  • call function on existing contract
  • read or write to name registry
  • manage permissions of accounts
  • run tests and assert on result
  • bond and unbond validators
  • create proposals or vote for a proposal

burrow deploy needs a script to its commands. This script format bares some similarity to ansible. It is in yaml format. The top level structure is an array of jobs. The different job types are defined here.

You can invoke burrow from the command line:

burrow deploy -a CF8F9480252B70D59CF5B5F3CAAA75FEAF6A4B33 deploy.yaml

Each job in the playbook has a name. This name can be used in later jobs to refer to the result of a previous job (e.g. the address of a contract which was deployed). The jobs are executed in-order.

Whenever an account needs to be specified, the key name in the burrow keys server can also be used.

Deploy

The deploy job compiles a solidity source file to a bin file which is then deployed to the chain. This type of job has the following parameters:

  • source: the input address from which to do the deploy transaction
  • contract: the path to the solidity source file
  • instance: once solidity source file can contain multiple contracts. This field is ignored if there is only one contract in the source. If there are multiple, the contract must match the filename, else this field. If this field is set to "all", all contracts in will be deployed.
  • libraries: list of the library address to link against
  • data: the arguments to the contract's constructor

The solidity source file is compiled using the solidity compiler unless the --wasm argument was given on the burrow deploy command line, in which case the solang compiler is used.

The contract is deployed with its metadata, so that we can retrieve the ABI when we need to call a function of this contract. For this reason, the bin file is a modified version of the solidity output json.

A solidity source file can have any number of contracts, and those contract names do not have to match the file name of the source. The resulting bin file(s) is named according to the name of the contract(s). To select which contracts to use, specifiy the instance field.

If the contract is specified as a bin file, compilation will be skipped. It can be useful to separate compilation from deployment using the build job, which is described next.

Build

The build job is used to only compile solidity and do not do any deployment. This only has one parameter:

  • contract: the path to the solidity source

Call / Query-Contract

The call and query contract job is for executing contract code by way of running one of the functions. The call job will create a transaction and will have to wait until the next block to retrieve the result; the query-contract job is for accessing read-only functions which do not require write access. This type of job has the following parameters:

  • source: the input address which should execute the transaction
  • destination: the account to access
  • function: the name of the function to call
  • data: the arguments to the function call
  • bin: the path to the abi or bin file

The destination field can either be a hex encoding adress, the name of a key name (e.g. Root_0 or Participant_1), or the result of previous burrow deploy job. In the latter case the name of the job must be specified, prefixed with $.

If the contract was deployed without metadata (e.g. using the burrow js module or with an earlier version of burrow deploy) the abi must be specified. This must be the path to the contract bin file or abi file.

Proposal

This is described in the proposal tutorial.