[bisq-network/bisq] Add Makefile for automating localnet setup (#3718)

[Chris Beams]

cbeams commented on this pull request.



> +	# 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'); \

> Doing a clean-rebuild takes a very long time and is not practical for quick iteration cycles.

Here's what I'm doing in practice as I develop stuff. The following assumes I have already done a `make deploy`, and that now I'm iterating on something, using my `alice` desktop node to see my changes live:
```
# quit my running `alice` node, e.g. with CMD-Q in the UI or ^C on the running process
./gradlew :desktop:build && make alice
```
This picks up and rebuilds just the changes I've made and then deploys those new bits as `alice`.

> Couldn't we ensure somehow that the build runs just once before deploying the individual nodes.

It does effectively run just once. The individual node deployment targets, e.g. `alice` and `bob` depend on `build`. Note that build is, in the latest commits, actually included once again in PHONY, so it does run every time, but that target just depends on the more specific `desktop/build` and `seednode/build` targets, which in turn run only if their respective directories do *not* already exist. The effect here is that when we deploy more than one node or all of them via `make deploy`, the `{desktop|seednode}/build` targets get run once and only once, avoiding the above mentioned race condition and inefficient contention for Gradle resources. If you want to cause a fast (incremental) rebuild, it's simply necessary to drop down to calling gradle directly like I've shown above. calling `make clean-build` should not be necessary in any case, unless you actually want to blow away all the build directories.

> Is there a significant advantage of having all the individual node commands depend on setup/build that I'm missing?

It just ensures that deploying any given node causes `build` and `localnet` to run if they have not already done so. So someone can come along in a clean checkout and run only `make bitcoind` and `make seednode` and everything will work as they expect, meaning that the .localnet dir will get created and the seednode build will run. If that's already happened, then those targets are no-ops.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/3718#discussion_r354500885
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191205/e74d5ef3/attachment.html>