Getting started is super easy: just run these commands under Linux or MacOS:
git clone git@github.com:fornellas/rrb.git
cd rrb/
./make.sh ci # runs linters, tests and buildThat's it! The local build happens inside a Docker, so it is easily reproducible on any machine.
If you're running an old Arm Mac (eg: M1), Docker is very slow, you should consider a no container build (see below).
You can start a development shell, which gives you access to the whole build environemnt, including all build tools with the correct versions. Eg:
./make.sh shell
make ci
go get -uYou may also run the unofficial1 build, without a container. This requires Installing GNU Make:
- Ubuntu:
apt install make. - MacOS:
brew install make2
Then:
make ci # on MacOS, gmake ciOr start a bash3 development shell:
make shellYour editor may already support using gopls, and you should follow its documentation on how to set it up. This may require having the correct go (and gopls) versions installed and available for your editor. This can be annoying and error prone.
In this scenario, you should leverage the "no container" option:
make shell
make ci # installs all development toolsAnd then start you code editor from the development shell (eg: for Sublime, do subl .). This enables the code editor to have access to all the exact versions of tools required.
The default build with ci reproduces the official build, but this may be too slow during development. You can use one of the *-dev targets to do a "dev build": bulid is a lot faster, at the expense of minimal signal loss:
./make.sh ci-dev # or "make ci-dev"The build system is integrated with rrb, which enables the build to run automatically as you edit the files.
First, start rrb:
./make.sh rrb # or "make rrb"then just edit the files with your preferred editor. As soon as you save any file, the build will be automatically run, interrupting any ongoing build, so you always get a fresh signal.
There's also a rrb-dev target, which yields faster builds during development.
Footnotes
-
unnofficial in the sense that it is not the same as it happens on CI, as unforeseen environment differences may impact the signal. Additionally, a lot of code / tests is Linux only (eg:
*_linux.go), so none of this signal will be available on MacOS. ↩ -
note that brew install the command as
gmake. Apple's ancientmakeshipped with MacOS will NOT work. ↩ -
bash must be installed separately, eg, under MacOS,
brew install bash. ↩