2021Q2全国联动黑客松大赛参赛源码+学习说明.zip

# Using docker-compose for local development The docker-compose configuration present in this directory allows for a user to quickly setup all of chainlink's services to perform actions like integration tests, acceptance tests, and development across multiple services. # Requirements - [docker-compose](https://docs.docker.com/compose/install/) # Using the compose script Inside the `chainlink/tools/docker` directory, there is a helper script that is included which should cover all cases of integration / acceptance / development needs acroos multiple services. To see a list of available commands, perform the following: ```sh cd tools/docker ./compose help ``` ## Examples ### Acceptance testing Acceptance can be accomplished by using the `acceptance` command. ```sh ./compose acceptance ``` - The explorer can be reached at `http://localhost:8080` - The chainlink node can be reached at `http://localhost:6688` Credentials for logging into the operator-ui can be found [here](../../tools/secrets/apicredentials) ### ### Doing local development on the core node Doing quick, iterative changes on the core codebase can still be achieved within the compose setup with the `cld` or `cldo` commands. The `cld` command will bring up the services that a chainlink node needs to connect to (explorer, parity/geth, postgres), and then attach the users terminal to a docker container containing the host's chainlink repository bind-mounted inside the container at `/usr/local/src/chainlink`. What this means is that any changes made within the host's repository will be synchronized to the container, and vice versa for changes made within the container at `/usr/local/src/chainlink`. This enables a user to make quick changes on either the container or the host, run `cldev` within the attached container, check the new behaviour of the re-built node, and repeat this process until the desired results are achieved. ```sh ./compose cld # # Now you are inside the container cldev # cldev without the "core" postfix simply calls the core node cli # # NAME: # main - CLI for Chainlink # # USAGE: # main [global options] command [command options] [arguments...] # # VERSION: # unset@unset # # COMMANDS: # admin Commands for remotely taking admin related actions # bridges Commands for Bridges communicating with External Adapters # config Commands for the node's configuration # jobs Commands for managing Jobs # node, local Commands for admin actions that must be run locally # runs Commands for managing Runs # txs Commands for handling Ethereum transactions # agreements, agree Commands for handling service agreements # attempts, txas Commands for managing Ethereum Transaction Attempts # createextrakey Create a key in the node's keystore alongside the existing key; to create an original key, just run the node # initiators Commands for managing External Initiators # help, h Shows a list of commands or help for one command # # GLOBAL OPTIONS: # --json, -j json output as opposed to table # --help, -h show help # --version, -v print the version cldev core # import our testing key and api credentials, then start the node # # ** Importing default key 0x9ca9d2d5e04012c9ed24c0e513c9bfaa4a2dd77f # 2019-12-11T20:31:18Z [INFO] Locking postgres for exclusive access with 500ms timeout orm/orm.go:74 # # 2019-12-11T20:31:18Z [WARN] pq: relation "migrations" does not exist migrations/migrate.go:149 # ** Running node # 2019-12-11T20:31:20Z [INFO] Starting Chainlink Node 0.7.0 at commit 7324e9c476ed6b5c0a08d5a38779d4a6bfbb3880 cmd/local_client.go:27 # ... # ... ``` `cldo` allows the user to perform the same actions above, but also applied to the operator-ui codebase and the core codebase. The operator-ui will be hosted in hot-reload/development mode at `http://localhost//3000`. To see the build progress of operator-ui, we can open another terminal to watch its output while we can mess around with the core node in the original terminal. In the first terminal: ```sh ./compose cldo # # Now you are inside the container cldev # cldev without the "core" postfix simply calls the core node cli # # NAME: # main - CLI for Chainlink # # USAGE: # main [global options] command [command options] [arguments...] # # VERSION: # unset@unset # # COMMANDS: # admin Commands for remotely taking admin related actions # bridges Commands for Bridges communicating with External Adapters # config Commands for the node's configuration # jobs Commands for managing Jobs # node, local Commands for admin actions that must be run locally # runs Commands for managing Runs # txs Commands for handling Ethereum transactions # agreements, agree Commands for handling service agreements # attempts, txas Commands for managing Ethereum Transaction Attempts # createextrakey Create a key in the node's keystore alongside the existing key; to create an original key, just run the node # initiators Commands for managing External Initiators # help, h Shows a list of commands or help for one command # # GLOBAL OPTIONS: # --json, -j json output as opposed to table # --help, -h show help # --version, -v print the version cldev core # import our testing key and api credentials, then start the node # # ** Importing default key 0x9ca9d2d5e04012c9ed24c0e513c9bfaa4a2dd77f # 2019-12-11T20:31:18Z [INFO] Locking postgres for exclusive access with 500ms timeout orm/orm.go:74 # # 2019-12-11T20:31:18Z [WARN] pq: relation "migrations" does not exist migrations/migrate.go:149 # ** Running node # 2019-12-11T20:31:20Z [INFO] Starting Chainlink Node 0.7.0 at commit 7324e9c476ed6b5c0a08d5a38779d4a6bfbb3880 cmd/local_client.go:27 # ... # ... ``` In a new terminal: ```sh docker logs operator-ui -f ``` You'll now have two terminals, one with the core node, one with operator-ui, with both being able to react to code changes without rebuilding their respective images. ### Running integration test suites The integration test suite will run against a parity node by default. You can run the integration test suite with the following command: ```sh ./compose test ``` If you want to run the test suite against a geth node, you can set the `GETH_MODE` environment variable. ```sh GETH_MODE=true ./compose test ``` If we want to quickly test new changes we make to `integration/` or `tools/ci/ethereum_test` without re-building our images, we can use the `test:dev` command which will reflect those changes from the host file system without rebuilding those containers. ```sh ./compose test:dev ``` Still a work in progress, you can run the tests in typescript (instead of bash) by using ```sh ./compose test:ts # or ./compose test:ts:dev ``` Eventually, these tests should replace the bash tests entirely ### Running specifically cypress tests See the README within the [integration folder.](../../integration/README.md) ### Cleaning up To remove any containers, volumes, and networks related to our docker-compose setup, we can run the `clean` command: ```sh ./compose clean ``` Individual clean commands are included for CI purposes when matrix jobs are being executed. ```sh ./compose test:down ./compose test:ts:down ``` ### Running your own commands based off of docker-compose The following commands allow you do just about anything: ```sh ./compose <subcommand> ./compose integration <subcommand> # or ./compose i ./compose dev:integration <subcommand> # or ./compose di ./compose dev <subcommand> ``` For example, to see what our compose configuration looks like: ```sh ./compose config # base config ./compose dev:integration # development integration test config ``` Or, to run just