mirrors/bisq
1
0
Fork 0
mirror of https://github.com/bisq-network/bisq.git synced 2024-11-19 01:41:11 +01:00
Code Issues Packages Projects Releases Wiki Activity
5fb4b2156c
bisq/Makefile
Chris Beams 5fb4b2156c
Refine deploy target for better use of screen 
Problem: Prior to this change, it was necessary to first create and
attach to a screen session and then to run `make deploy` within it. This
meant extra steps for the user and was generally error-prone.

Solution: Usage of screen has been refined such that a screen session
named 'localnet' is created on the users behalf without any need to
attach to it. Individual node deployment targets such as `make
bitcoind`, `make alice`, et al. are issued to new windows within the
localnet screen session, and the user is free to attach or not whenever
they choose. The result is that a new user can clone the repository and
type nothing more than `make deploy` to get up and running with their
localnet.

This also reverts the changes in commit 97dd342e5 ("Make build target
phony") for the following reasons:

 - As mentioned in that commit message, Gradle was not deleting the its
   'build' directory when running `gradle clean`, meaning that the
   'build' target was always up-to-date, even after running `make
   clean`. This made it impossible to get a correct rebuild workflow. On
   analysis, howewer, this situation was because of a badly behaving
   Kotlin plugin not cleaning up after itself, leaving a subdirectory at
   build/kotlin and preventing the build directory itself from being
   deleted altogether. To address this, the `make clean` target has been
   updated to `rm -rf build` instead of calling `build gradle`. While
   it's a workaround until we back out the Kotlin changes that caused
   this, it does have the added benefit of being faster than invoking
   `gradle clean`.

 - By making the 'build' target PHONY, this meant that `./gradlew build`
   was getting invoked every time a dependent target was called. For
   example, `make alice` depends on the 'setup' target, which in turn
   depends on the 'build' target. When calling such targets in
   isolation, this arrangement works out fine, because the phony 'build'
   target always runs, invoking `./gradle build`, and the Gradle build
   completes quickly assuming everything is up-to-date. The problem
   arises when calling a number of these targets in rapid succession, as
   we do when calling `make deploy` and running each individual node
   target in its own screen window. This causes contention in two ways.
   The first is that these multiple, simultaneous Gradle processes
   compete for access to an available Gradle daemon, and because each
   process needs its own, it ends up that as many Gradle daemons get
   created as Bisq nodes we need to deploy (5 in total). This is a big
   waste of time and resources. The second way it causes not only
   contention but outright failure is that each of these builds are
   operating in the same directory, and while most aspects of the build
   are in fact up-to-date and therefore not modified in any way, there
   are exceptions to this rule. The result is that build artifacts, e.g.
   jars are getting deleted and rebuilt from underneath competing Gradle
   processes, and all manner of chaos ensues, such as NoClassDefFound
   errors and much more. This change (reverting 'build' back to a
   normal, non-phony target) avoids these problems entirely. When
   running `make deploy`, we run the 'build' target once as a function
   of the 'deploy' target depending on it. At this point, the 'build'
   directory exists, and all subsequent node deployment targets, e.g.
   'alice', 'bob', etc do not re-run the build target because it is
   up-to-date. For workflows where the user definitely wants to rebuild
   prior to redeploying a given node, they can either run `make
   clean-build`, or drop down to issuing Gradle build commands directly,
   e.g. `./gradlew :desktop:build` followed by `make desktop`.
2019-12-02 20:15:02 +01:00

247 lines
7.3 KiB
Makefile
Raw Blame History

#
# INTRODUCTION
#
# This makefile is designed to help Bisq contributors get up and running
# as quickly as possible with a local regtest Bisq network deployment,
# or 'localnet' for short. A localnet is a complete and self-contained
# "mini Bisq network" suitable for development and end-to-end testing
# efforts.
#
#
# REQUIREMENTS
#
# You'll need the following to proceed:
#
# - Linux, macOS or similar *nix with standard tools like `make`
# - bitcoind and bitcoin-cli (`brew install bitcoin` on macOS)
# - JDK 10 to build and run Bisq binaries; see
# https://www.oracle.com/java/technologies/java-archive-javase10-downloads.html
#
#
# USAGE
#
# The following commands (and a couple manual instructions) will get
# your localnet up and running quickly.
#
# STEP 1: Build all Bisq binaries and set up localnet resources. This
# will take a few minutes the first time through.
#
# $ make
#
# Notes:
#
# - When complete, you'll have a number of scripts available in the
# root directory. They will be used in the make targets below to start
# the various Bisq seed and desktop nodes that will make up your
# localnet:
#
# $ ls -1 bisq-*
# bisq-desktop
# bisq-monitor
# bisq-pricenode
# bisq-relay
# bisq-seednode
# bisq-statsnode
#
# - You will see a new '.localnet' directory containing the data dirs
# for your regtest Bitcoin and Bisq nodes. Once you've deployed them in
# the step below, the directory will look as follows:
#
# $ tree -d -L 1 .localnet
# .localnet
# ├── alice
# ├── bitcoind
# ├── bob
# ├── mediator
# ├── seednode
# └── seednode2
#
# STEP 2: Deploy the Bitcoin and Bisq nodes that make up the localnet.
# Run each of the following in a SEPARATE TERMINAL WINDOW, as they are
# long-running processes.
#
# $ make bitcoind
# $ make seednode
# $ make seednode2
# $ make mediator
# $ make alice
# $ make bob
#
# Tip: Those familiar with the `screen` terminal multiplexer can
# automate the above by running the `deploy` target found below.
#
# Notes:
#
# - The 'seednode' targets launch headless Bisq nodes that help
# desktop nodes discover other peers, as well as storing and
# forwarding p2p network messages for nodes as they go on and
# offline.
#
# - As you run the 'mediator', 'alice' and 'bob' targets above,
# you'll see a Bisq desktop node window appear for each. The Alice
# and Bob instances represent two traders who can make and take
# offers with one another. The Mediator instance represents a Bisq
# contributor who can help resolve any technical problems or disputes
# that come up between the two traders.
#
# STEP 3: Configure the mediator Bisq node. In order to make and take
# offers, Alice and Bob will need to have a mediator and a refund agent
# registered on the network. Follow the instructions below to complete
# that process:
#
# a) Go to the Account screen in the Mediator instance and press CMD+N
# and a popup will appear. Click 'Unlock' and then click 'Register' to
# register the instance as a mediator.
#
# b) While still in the Account screen, press CMD+D and follow the same
# steps as above to register the instance as a refund agent.
#
# When the steps above are complete, your localnet should be up and
# ready to use. You can now test in isolation all Bisq features and use
# cases.
#
# Set up everything necessary for deploying your localnet. This is the
# default target.
setup: build .localnet
clean: clean-build clean-localnet
clean-build:
rm -rf build
clean-localnet:
rm -rf .localnet ./dao-setup
# Build all Bisq binaries and generate the shell scripts used to run
# them in the targets below
build:
./gradlew build
# Unpack and customize a Bitcoin regtest node and Alice and Bob Bisq
# nodes that have been preconfigured with a blockchain containing the
# BSQ genesis transaction
.localnet:
# Unpack the old dao-setup.zip and move things around for more
# concise and intuitive naming. This is a temporary measure until we
# clean these resources up more thoroughly.
unzip docs/dao-setup.zip
mv dao-setup .localnet
mv .localnet/Bitcoin-regtest .localnet/bitcoind
mv .localnet/bisq-BTC_REGTEST_Alice_dao .localnet/alice
mv .localnet/bisq-BTC_REGTEST_Bob_dao .localnet/bob
# Remove the preconfigured bitcoin.conf in favor of explicitly
# parameterizing the invocation of bitcoind in the target below
rm -v .localnet/bitcoind/bitcoin.conf
# Avoid spurious 'runCommand' errors in the bitcoind log when nc
# fails to bind to one of the listed block notification ports
echo exit 0 >> .localnet/bitcoind/blocknotify
# Alias '.localnet' to 'localnet' so the target is discoverable in tab
# completion
localnet: .localnet
# Deploy a complete localnet by running all required Bitcoin and Bisq
# nodes, each in their own named screen window. If you are not a screen
# user, you'll need to manually run each of the targets listed below
# commands manually in a separate terminal or as background jobs.
deploy: setup
# create a new screen session named 'localnet'
screen -dmS localnet
# deploy each node in its own named screen window
targets=('bitcoind' 'seednode' 'seednode2' 'alice' 'bob' 'mediator'); \
for t in "$${targets[@]}"; do \
screen -S localnet -X screen -t $$t; \
screen -S localnet -p $$t -X stuff "make $$t\n"; \
done;
# give bitcoind rpc server time to start
sleep 5
# generate a block to ensure Bisq nodes get dao-synced
make block
bitcoind: .localnet
bitcoind \
-regtest \
-prune=0 \
-txindex=1 \
-server \
-rpcuser=bisqdao \
-rpcpassword=bsq \
-datadir=.localnet/bitcoind \
-blocknotify='.localnet/bitcoind/blocknotify %s'
seednode: build
./bisq-seednode \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--fullDaoNode=true \
--rpcUser=bisqdao \
--rpcPassword=bsq \
--rpcBlockNotificationPort=5120 \
--nodePort=2002 \
--userDataDir=.localnet \
--appName=seednode
seednode2: build
./bisq-seednode \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--fullDaoNode=true \
--rpcUser=bisqdao \
--rpcPassword=bsq \
--rpcBlockNotificationPort=5121 \
--nodePort=3002 \
--userDataDir=.localnet \
--appName=seednode2
mediator: build
./bisq-desktop \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--nodePort=4444 \
--appDataDir=.localnet/mediator \
--appName=Mediator
alice: setup
./bisq-desktop \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--nodePort=5555 \
--fullDaoNode=true \
--rpcUser=bisqdao \
--rpcPassword=bsq \
--rpcBlockNotificationPort=5122 \
--genesisBlockHeight=111 \
--genesisTxId=30af0050040befd8af25068cc697e418e09c2d8ebd8d411d2240591b9ec203cf \
--appDataDir=.localnet/alice \
--appName=Alice
bob: setup
./bisq-desktop \
--baseCurrencyNetwork=BTC_REGTEST \
--useLocalhostForP2P=true \
--useDevPrivilegeKeys=true \
--nodePort=6666 \
--appDataDir=.localnet/bob \
--appName=Bob
# Generate a new block on your Bitcoin regtest network. Requires that
# bitcoind is already running. See the `bitcoind` target above.
block:
bitcoin-cli \
-regtest \
-rpcuser=bisqdao \
-rpcpassword=bsq \
getnewaddress \
| xargs bitcoin-cli \
-regtest \
-rpcuser=bisqdao \
-rpcpassword=bsq \
generatetoaddress 1
.PHONY: seednode
Reference in New Issue View Git Blame Copy Permalink