Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
#
|
|
|
|
|
# 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)
|
2021-04-22 11:33:57 +02:00
|
|
|
# - JDK 11 to build and run Bisq binaries; see
|
2021-04-23 10:31:11 +02:00
|
|
|
# https://jdk.java.net/archive/
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
#
|
|
|
|
|
#
|
|
|
|
|
# USAGE
|
|
|
|
|
#
|
2019-12-02 17:52:28 +01:00
|
|
|
# The following commands (and a couple manual instructions) will get
|
|
|
|
|
# your localnet up and running quickly.
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
#
|
2019-12-02 17:52:28 +01:00
|
|
|
# STEP 1: Build all Bisq binaries and set up localnet resources. This
|
|
|
|
|
# will take a few minutes the first time through.
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
#
|
|
|
|
|
# $ 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-seednode
|
|
|
|
|
# bisq-statsnode
|
|
|
|
|
#
|
2019-11-30 07:50:59 +01:00
|
|
|
# - You will see a new '.localnet' directory containing the data dirs
|
2019-12-02 17:52:28 +01:00
|
|
|
# for your regtest Bitcoin and Bisq nodes. Once you've deployed them in
|
|
|
|
|
# the step below, the directory will look as follows:
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
#
|
2019-11-30 07:50:59 +01:00
|
|
|
# $ tree -d -L 1 .localnet
|
|
|
|
|
# .localnet
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
# ├── 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:
|
|
|
|
|
#
|
2021-03-17 08:26:25 +01:00
|
|
|
# a) Go to the Account screen in the Mediator instance and press CMD+D
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
# and a popup will appear. Click 'Unlock' and then click 'Register' to
|
|
|
|
|
# register the instance as a mediator.
|
|
|
|
|
#
|
2021-03-17 08:26:25 +01:00
|
|
|
# b) While still in the Account screen, press CMD+N and follow the same
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
# 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.
|
Review "Use STATE_DIR := .localnet in makefile"
This change follows up on commit 650c5894d, which:
1. Renamed the 'localdir' directory to '.localdir' to better follow
convention with how local data directories are often managed, e.g.
.git and .gradle.
2. Introduced the STATE_DIR variable to avoid duplication of the
'.localdir' string throughout the Makefile, and at least in concept to
allow this value to be customized via setting an environment variable.
The changes in (1) are preserved, while the changes in (2) have been
backed out. Rationale:
- The STATE_DIR name introduces a new concept to the reader. They must
reason about its meaning, and this works against the intention of the
Makefile, which is to maximize understandability for the uninitiated.
- The name, if we were to preserve the variable, probably should have
been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually
incorrect, but industry convention is to refer to such directories as
"data directories", e.g. Bitcoin Core's `datadir` option, LND's
`datadir` option and Bisq's `userDataDir` and `appDataDir` options.
- The variable, whatever its name, introduces a layer of indirection,
which while convenient to the makefile maintainer, is a barrier to
comprehension for the reader / contributor. For example, if a user
wished to copy and paste the recipe for a target, say 'bob' from the
makefile, with the varible in place, the user would have to figure
out its correct value and replace it before they could paste and use
the copied command. Like in the first note above, the idea with the
makefile is to maximize understanding for the uninitiated, i.e.
working code as executable documentation. It is reasonable given this
goal to increase the burden on a few maintainers in order to ease the
potentially many contributors.
Finally, this change follows up on the renaming of the 'localnet'
directory to '.localnet' by reflecting this change in the name of the
associated target as well. This is order to avoid dependent targets e.g.
'bitcoind', 'alice' or 'bob' constantly re-running the localnet target.
In turn it also adds an 'alias' target named 'localnet' (without the
leading dot) because targets with a leading dot are (I believe) treated
as "implicit targets". In any case, they do not show up in a tab
completion context, so introducing the normally-named alias fixes that.
This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
|
|
|
setup: build .localnet
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
|
|
|
|
|
clean: clean-build clean-localnet
|
|
|
|
|
|
|
|
|
|
clean-build:
|
Make 'build' target phony once again
In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was
made normal, i.e. non-phony, but on further review it does in fact make
sense to declare 'build' phony, such that it is run no matter the status
of the root-level 'build' directory, but for different reasons.
Previously, we had been considering the presence of 'build' directory as
a reasonable proxy for determining whether the `./gradlew build` had
been run. If the directory was present, we considered the 'build' target
up-to-date. If not, then we would re-run `./gradlew build`. This is all
sensible enough, except for the fact that the root-level 'build'
directory has almost nothing to do with the actual output of `./gradlew
build`. Gradle does output 'build' directories, but in the respective
subdirectory for each module of the project. After `./gradlew build` has
been run, we would see a 'desktop/build' directory, a 'seednode/build'
directory and so forth. It just so happens that a root-level 'build'
directory was getting created at all due to idiosyncracies of a
particular Kotlin plugin.
This commit updates the makefile to better respect this reality by:
- preserving the 'build' target but marking it once again as PHONY
- introducing new 'seednode/build' and 'desktop/build' targets that
trigger './gradlew :seednode:build` and ./gradlew :desktop:build`
commands respectively.
- making 'build' depend on these two new targets
In light of this realization of flawed thinking about the root-level
build dir, this change also restores `make clean` to calling `./gradlew
clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
|
|
|
./gradlew clean
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
|
|
|
|
|
clean-localnet:
|
Review "Use STATE_DIR := .localnet in makefile"
This change follows up on commit 650c5894d, which:
1. Renamed the 'localdir' directory to '.localdir' to better follow
convention with how local data directories are often managed, e.g.
.git and .gradle.
2. Introduced the STATE_DIR variable to avoid duplication of the
'.localdir' string throughout the Makefile, and at least in concept to
allow this value to be customized via setting an environment variable.
The changes in (1) are preserved, while the changes in (2) have been
backed out. Rationale:
- The STATE_DIR name introduces a new concept to the reader. They must
reason about its meaning, and this works against the intention of the
Makefile, which is to maximize understandability for the uninitiated.
- The name, if we were to preserve the variable, probably should have
been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually
incorrect, but industry convention is to refer to such directories as
"data directories", e.g. Bitcoin Core's `datadir` option, LND's
`datadir` option and Bisq's `userDataDir` and `appDataDir` options.
- The variable, whatever its name, introduces a layer of indirection,
which while convenient to the makefile maintainer, is a barrier to
comprehension for the reader / contributor. For example, if a user
wished to copy and paste the recipe for a target, say 'bob' from the
makefile, with the varible in place, the user would have to figure
out its correct value and replace it before they could paste and use
the copied command. Like in the first note above, the idea with the
makefile is to maximize understanding for the uninitiated, i.e.
working code as executable documentation. It is reasonable given this
goal to increase the burden on a few maintainers in order to ease the
potentially many contributors.
Finally, this change follows up on the renaming of the 'localnet'
directory to '.localnet' by reflecting this change in the name of the
associated target as well. This is order to avoid dependent targets e.g.
'bitcoind', 'alice' or 'bob' constantly re-running the localnet target.
In turn it also adds an 'alias' target named 'localnet' (without the
leading dot) because targets with a leading dot are (I believe) treated
as "implicit targets". In any case, they do not show up in a tab
completion context, so introducing the normally-named alias fixes that.
This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
|
|
|
rm -rf .localnet ./dao-setup
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
|
Make 'build' target phony once again
In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was
made normal, i.e. non-phony, but on further review it does in fact make
sense to declare 'build' phony, such that it is run no matter the status
of the root-level 'build' directory, but for different reasons.
Previously, we had been considering the presence of 'build' directory as
a reasonable proxy for determining whether the `./gradlew build` had
been run. If the directory was present, we considered the 'build' target
up-to-date. If not, then we would re-run `./gradlew build`. This is all
sensible enough, except for the fact that the root-level 'build'
directory has almost nothing to do with the actual output of `./gradlew
build`. Gradle does output 'build' directories, but in the respective
subdirectory for each module of the project. After `./gradlew build` has
been run, we would see a 'desktop/build' directory, a 'seednode/build'
directory and so forth. It just so happens that a root-level 'build'
directory was getting created at all due to idiosyncracies of a
particular Kotlin plugin.
This commit updates the makefile to better respect this reality by:
- preserving the 'build' target but marking it once again as PHONY
- introducing new 'seednode/build' and 'desktop/build' targets that
trigger './gradlew :seednode:build` and ./gradlew :desktop:build`
commands respectively.
- making 'build' depend on these two new targets
In light of this realization of flawed thinking about the root-level
build dir, this change also restores `make clean` to calling `./gradlew
clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
|
|
|
# Build Bisq binaries and shell scripts used in the targets below
|
|
|
|
|
build: seednode/build desktop/build
|
|
|
|
|
|
|
|
|
|
seednode/build:
|
|
|
|
|
./gradlew :seednode:build
|
|
|
|
|
|
|
|
|
|
desktop/build:
|
|
|
|
|
./gradlew :desktop:build
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
|
|
|
|
|
# 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
|
Review "Use STATE_DIR := .localnet in makefile"
This change follows up on commit 650c5894d, which:
1. Renamed the 'localdir' directory to '.localdir' to better follow
convention with how local data directories are often managed, e.g.
.git and .gradle.
2. Introduced the STATE_DIR variable to avoid duplication of the
'.localdir' string throughout the Makefile, and at least in concept to
allow this value to be customized via setting an environment variable.
The changes in (1) are preserved, while the changes in (2) have been
backed out. Rationale:
- The STATE_DIR name introduces a new concept to the reader. They must
reason about its meaning, and this works against the intention of the
Makefile, which is to maximize understandability for the uninitiated.
- The name, if we were to preserve the variable, probably should have
been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually
incorrect, but industry convention is to refer to such directories as
"data directories", e.g. Bitcoin Core's `datadir` option, LND's
`datadir` option and Bisq's `userDataDir` and `appDataDir` options.
- The variable, whatever its name, introduces a layer of indirection,
which while convenient to the makefile maintainer, is a barrier to
comprehension for the reader / contributor. For example, if a user
wished to copy and paste the recipe for a target, say 'bob' from the
makefile, with the varible in place, the user would have to figure
out its correct value and replace it before they could paste and use
the copied command. Like in the first note above, the idea with the
makefile is to maximize understanding for the uninitiated, i.e.
working code as executable documentation. It is reasonable given this
goal to increase the burden on a few maintainers in order to ease the
potentially many contributors.
Finally, this change follows up on the renaming of the 'localnet'
directory to '.localnet' by reflecting this change in the name of the
associated target as well. This is order to avoid dependent targets e.g.
'bitcoind', 'alice' or 'bob' constantly re-running the localnet target.
In turn it also adds an 'alias' target named 'localnet' (without the
leading dot) because targets with a leading dot are (I believe) treated
as "implicit targets". In any case, they do not show up in a tab
completion context, so introducing the normally-named alias fixes that.
This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
|
|
|
.localnet:
|
2019-12-02 17:52:28 +01:00
|
|
|
# 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.
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
unzip docs/dao-setup.zip
|
Review "Use STATE_DIR := .localnet in makefile"
This change follows up on commit 650c5894d, which:
1. Renamed the 'localdir' directory to '.localdir' to better follow
convention with how local data directories are often managed, e.g.
.git and .gradle.
2. Introduced the STATE_DIR variable to avoid duplication of the
'.localdir' string throughout the Makefile, and at least in concept to
allow this value to be customized via setting an environment variable.
The changes in (1) are preserved, while the changes in (2) have been
backed out. Rationale:
- The STATE_DIR name introduces a new concept to the reader. They must
reason about its meaning, and this works against the intention of the
Makefile, which is to maximize understandability for the uninitiated.
- The name, if we were to preserve the variable, probably should have
been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually
incorrect, but industry convention is to refer to such directories as
"data directories", e.g. Bitcoin Core's `datadir` option, LND's
`datadir` option and Bisq's `userDataDir` and `appDataDir` options.
- The variable, whatever its name, introduces a layer of indirection,
which while convenient to the makefile maintainer, is a barrier to
comprehension for the reader / contributor. For example, if a user
wished to copy and paste the recipe for a target, say 'bob' from the
makefile, with the varible in place, the user would have to figure
out its correct value and replace it before they could paste and use
the copied command. Like in the first note above, the idea with the
makefile is to maximize understanding for the uninitiated, i.e.
working code as executable documentation. It is reasonable given this
goal to increase the burden on a few maintainers in order to ease the
potentially many contributors.
Finally, this change follows up on the renaming of the 'localnet'
directory to '.localnet' by reflecting this change in the name of the
associated target as well. This is order to avoid dependent targets e.g.
'bitcoind', 'alice' or 'bob' constantly re-running the localnet target.
In turn it also adds an 'alias' target named 'localnet' (without the
leading dot) because targets with a leading dot are (I believe) treated
as "implicit targets". In any case, they do not show up in a tab
completion context, so introducing the normally-named alias fixes that.
This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
|
|
|
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
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
# Remove the preconfigured bitcoin.conf in favor of explicitly
|
|
|
|
|
# parameterizing the invocation of bitcoind in the target below
|
Review "Use STATE_DIR := .localnet in makefile"
This change follows up on commit 650c5894d, which:
1. Renamed the 'localdir' directory to '.localdir' to better follow
convention with how local data directories are often managed, e.g.
.git and .gradle.
2. Introduced the STATE_DIR variable to avoid duplication of the
'.localdir' string throughout the Makefile, and at least in concept to
allow this value to be customized via setting an environment variable.
The changes in (1) are preserved, while the changes in (2) have been
backed out. Rationale:
- The STATE_DIR name introduces a new concept to the reader. They must
reason about its meaning, and this works against the intention of the
Makefile, which is to maximize understandability for the uninitiated.
- The name, if we were to preserve the variable, probably should have
been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually
incorrect, but industry convention is to refer to such directories as
"data directories", e.g. Bitcoin Core's `datadir` option, LND's
`datadir` option and Bisq's `userDataDir` and `appDataDir` options.
- The variable, whatever its name, introduces a layer of indirection,
which while convenient to the makefile maintainer, is a barrier to
comprehension for the reader / contributor. For example, if a user
wished to copy and paste the recipe for a target, say 'bob' from the
makefile, with the varible in place, the user would have to figure
out its correct value and replace it before they could paste and use
the copied command. Like in the first note above, the idea with the
makefile is to maximize understanding for the uninitiated, i.e.
working code as executable documentation. It is reasonable given this
goal to increase the burden on a few maintainers in order to ease the
potentially many contributors.
Finally, this change follows up on the renaming of the 'localnet'
directory to '.localnet' by reflecting this change in the name of the
associated target as well. This is order to avoid dependent targets e.g.
'bitcoind', 'alice' or 'bob' constantly re-running the localnet target.
In turn it also adds an 'alias' target named 'localnet' (without the
leading dot) because targets with a leading dot are (I believe) treated
as "implicit targets". In any case, they do not show up in a tab
completion context, so introducing the normally-named alias fixes that.
This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
|
|
|
rm -v .localnet/bitcoind/bitcoin.conf
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
# Avoid spurious 'runCommand' errors in the bitcoind log when nc
|
|
|
|
|
# fails to bind to one of the listed block notification ports
|
Review "Use STATE_DIR := .localnet in makefile"
This change follows up on commit 650c5894d, which:
1. Renamed the 'localdir' directory to '.localdir' to better follow
convention with how local data directories are often managed, e.g.
.git and .gradle.
2. Introduced the STATE_DIR variable to avoid duplication of the
'.localdir' string throughout the Makefile, and at least in concept to
allow this value to be customized via setting an environment variable.
The changes in (1) are preserved, while the changes in (2) have been
backed out. Rationale:
- The STATE_DIR name introduces a new concept to the reader. They must
reason about its meaning, and this works against the intention of the
Makefile, which is to maximize understandability for the uninitiated.
- The name, if we were to preserve the variable, probably should have
been something like DATA_DIR_ROOT. 'STATE_DIR' is not conceptually
incorrect, but industry convention is to refer to such directories as
"data directories", e.g. Bitcoin Core's `datadir` option, LND's
`datadir` option and Bisq's `userDataDir` and `appDataDir` options.
- The variable, whatever its name, introduces a layer of indirection,
which while convenient to the makefile maintainer, is a barrier to
comprehension for the reader / contributor. For example, if a user
wished to copy and paste the recipe for a target, say 'bob' from the
makefile, with the varible in place, the user would have to figure
out its correct value and replace it before they could paste and use
the copied command. Like in the first note above, the idea with the
makefile is to maximize understanding for the uninitiated, i.e.
working code as executable documentation. It is reasonable given this
goal to increase the burden on a few maintainers in order to ease the
potentially many contributors.
Finally, this change follows up on the renaming of the 'localnet'
directory to '.localnet' by reflecting this change in the name of the
associated target as well. This is order to avoid dependent targets e.g.
'bitcoind', 'alice' or 'bob' constantly re-running the localnet target.
In turn it also adds an 'alias' target named 'localnet' (without the
leading dot) because targets with a leading dot are (I believe) treated
as "implicit targets". In any case, they do not show up in a tab
completion context, so introducing the normally-named alias fixes that.
This is a follow-up to cbeams/bisq#3.
2019-12-02 17:04:48 +01:00
|
|
|
echo exit 0 >> .localnet/bitcoind/blocknotify
|
|
|
|
|
|
|
|
|
|
# Alias '.localnet' to 'localnet' so the target is discoverable in tab
|
|
|
|
|
# completion
|
|
|
|
|
localnet: .localnet
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
|
|
|
|
|
# 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
|
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 19:53:49 +01:00
|
|
|
# user, you'll need to manually run each of the targets listed below
|
|
|
|
|
# commands manually in a separate terminal or as background jobs.
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
deploy: setup
|
2023-09-11 20:03:44 +02:00
|
|
|
./gradlew :startRegtest
|
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 19:53:49 +01:00
|
|
|
# give bitcoind rpc server time to start
|
|
|
|
|
sleep 5
|
|
|
|
|
# generate a block to ensure Bisq nodes get dao-synced
|
|
|
|
|
make block
|
2023-09-11 20:03:44 +02:00
|
|
|
tail -f .localnet/bitcoind_shell.log \
|
|
|
|
|
.localnet/seednode_1_shell.log \
|
|
|
|
|
.localnet/seednode_2_shell.log \
|
|
|
|
|
.localnet/alice_shell.log \
|
|
|
|
|
.localnet/bob_shell.log \
|
|
|
|
|
.localnet/mediator_shell.log
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
|
2019-12-03 11:56:04 +01:00
|
|
|
# Undeploy a running localnet by killing all Bitcoin and Bisq
|
|
|
|
|
# node processes, then killing the localnet screen session altogether
|
|
|
|
|
undeploy:
|
2023-09-11 20:03:44 +02:00
|
|
|
./gradlew :stopRegtest
|
2019-12-03 11:56:04 +01:00
|
|
|
|
Add Makefile for automating localnet setup
Problem: contributors old and new must read and follow many manual steps
spread across three documents (docs/{build,dev-setup,dao-setup}.md) in
order to get up and running with a local regtest Bisq network deployment
suitable for isolated development and end-to-end testing. This process
is not only manual, but requires considerable trial and error for most
contributors, and can amount to hours of effort. Perhaps most
detrimental is that this friction makes it much less likely that we get
"all hands on deck" to cover test scenarios at release time. Getting up
and running with what this change refers to as a "localnet" should be
among the very first things a new contributor does. It should be fast
and easy, maximizing the contributor's ability to get productive right
away.
Solution: this commit introduces a simple and well-documented makefile
to the root of the source tree. It instructs the user to issue a series
of simple `make` commands, at the end of which they'll have a fully
functional localnet deployment.
Caveats:
- No support for Windows unless the user is running Git Bash, Cygwin or
similar. In any case, the makefile serves as clear documentation
about what a Windows user would need to do manually, i.e. without the
benefit of `make` automating it all.
- The aforementioned setup documents should be updated to point to this
makefile instead of explaining everything in prose. The dev-setup.md
and dao-setup.md documents may actually be candidates for deletion if
this new approach proves successful.
- These changes do not include passing the new -peerbloomfilters=1
option to bitcoin versions 0.19 and above. Those who have already
upgraded should take care to add that option.
Notes:
- The introduction of this makefile has no impact on Bisq's use of
Gradle as a build system. Everything there is as it has been. This
makefile is a completely optional convenience being added into the
mix. It has the added benefit of being a "friendly face" to those not
familiar with the Java / JVM ecosystem. Developers from many
different backgrounds are familiar with make and makefiles, and they
may find this one a pleasant and inviting surprise.
2019-11-30 00:11:07 +01:00
|
|
|
# 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
|
|
|
|
|
|
2021-03-25 17:23:34 +01:00
|
|
|
# Generate more than 1 block.
|
|
|
|
|
# Instead of running `make block` 24 times,
|
|
|
|
|
# you can now run `make blocks n=24`
|
|
|
|
|
blocks:
|
|
|
|
|
bitcoin-cli \
|
|
|
|
|
-regtest \
|
|
|
|
|
-rpcuser=bisqdao \
|
|
|
|
|
-rpcpassword=bsq \
|
|
|
|
|
getnewaddress \
|
|
|
|
|
| xargs bitcoin-cli \
|
|
|
|
|
-regtest \
|
|
|
|
|
-rpcuser=bisqdao \
|
|
|
|
|
-rpcpassword=bsq \
|
|
|
|
|
generatetoaddress $(n)
|
|
|
|
|
|
Make 'build' target phony once again
In commit 5fb4b21 ("Refine deploy target..."), the 'build' target was
made normal, i.e. non-phony, but on further review it does in fact make
sense to declare 'build' phony, such that it is run no matter the status
of the root-level 'build' directory, but for different reasons.
Previously, we had been considering the presence of 'build' directory as
a reasonable proxy for determining whether the `./gradlew build` had
been run. If the directory was present, we considered the 'build' target
up-to-date. If not, then we would re-run `./gradlew build`. This is all
sensible enough, except for the fact that the root-level 'build'
directory has almost nothing to do with the actual output of `./gradlew
build`. Gradle does output 'build' directories, but in the respective
subdirectory for each module of the project. After `./gradlew build` has
been run, we would see a 'desktop/build' directory, a 'seednode/build'
directory and so forth. It just so happens that a root-level 'build'
directory was getting created at all due to idiosyncracies of a
particular Kotlin plugin.
This commit updates the makefile to better respect this reality by:
- preserving the 'build' target but marking it once again as PHONY
- introducing new 'seednode/build' and 'desktop/build' targets that
trigger './gradlew :seednode:build` and ./gradlew :desktop:build`
commands respectively.
- making 'build' depend on these two new targets
In light of this realization of flawed thinking about the root-level
build dir, this change also restores `make clean` to calling `./gradlew
clean` instead of `rm -rf build`.
2019-12-02 21:25:59 +01:00
|
|
|
.PHONY: build seednode
|
