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

[Chris Beams]

Ok, I believe the latest commits here address most if not all of the feedback received so far. Please sync up, take it for another spin and let me know if you run into any problems. If everything works without error, I'd like to call this iteration "good enough", such that the PR can be merged and I can return to gRPC work. Further tweaks and improvements will no doubt be in order, but to the degree they're "nice-to-haves" let's try to manage them as subsequent PRs.

Here's what I consider the basic set of use cases that is supported right now, i.e. what should "just work" when you're using the makefile:

1. The 'get started from scratch' use case: `make deploy` in a fresh local bisq clone (or your freshly `clean`ed clone) should do everything from A to Z: it should build the desktop and seednode binaries, unpack and customize the dao-setup.zip file into the `.localnet` directory, and it should deploy bitcoind and all necessary Bisq nodes into a screen session named `localnet`.
2. The 'get started from scratch' without `screen` usecase: `make` followed by running each node deployment target, e.g. `make bitcoind`, `make seednode`, etc. in a separate window should get you up and running with everything.
3. The "I want to start over with the state of my nodes but I don't want to rebuild the binaries" use case. `make clean-localnet deploy` will take care of your needs. Don't forget to kill all your existing node processes and the screen session first, though.
4. The "I want to iterate on development and redeploy just one desktop node while leaving the rest of my localnet up and running" use case. Kill the desktop process in question, e.g. 'alice', make your changes to desktop sources and then run `make alice`. This will trigger the desktop build and deploy the alice node.
5. ... there are probably other nameable use cases that are supported in the current makefile, but these are the basics. Feel free to add to this list, but again, anything net new should probably be managed separately from this PR.

Remember, this stuff doesn't replace the gradle build and doesn't intend to become a comprehensive abstraction over it. It should handle the basics for new contributors who have enough to figure out without grokking gradle. Once you're into an actual development task, you should feel comfortable using gradle more surgically for whatever you need it to do, just as is expected today.

-- 
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#issuecomment-560573961
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191202/608e4339/attachment.html>