Skip to content

Commit

Permalink
[docs] add content to coredb contributor build/test (#15627)
Browse files Browse the repository at this point in the history
  • Loading branch information
jaki authored Jan 12, 2023
1 parent ae68668 commit 6ab3904
Show file tree
Hide file tree
Showing 10 changed files with 274 additions and 115 deletions.
1 change: 1 addition & 0 deletions .github/vale-styles/Yugabyte/spelling-exceptions.txt
Original file line number Diff line number Diff line change
Expand Up @@ -112,6 +112,7 @@ Citrix
Citus
clonable
Cloudwatch
CMake
Cobertura
Codepen
Cognito
Expand Down
6 changes: 3 additions & 3 deletions docs/content/preview/contribute/core-database/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -50,13 +50,13 @@ type: indexpage
</div>

<div class="col-12 col-md-6 col-lg-12 col-xl-6">
<a class="section-link icon-offset" href="run-unit-tests/">
<a class="section-link icon-offset" href="build-and-test/">
<div class="head">
<img class="icon" src="/images/section_icons/explore/json_documents.png" aria-hidden="true" />
<div class="title">Run unit tests</div>
<div class="title">Build and test</div>
</div>
<div class="body">
Run unit tests.
Building and testing with yb_build.sh.
</div>
</a>
</div>
Expand Down
248 changes: 248 additions & 0 deletions docs/content/preview/contribute/core-database/build-and-test.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,248 @@
---
title: Build and test
headerTitle: Build and test
linkTitle: Build and test
description: Build and test
image: /images/section_icons/index/quick_start.png
headcontent: Building and testing with yb_build.sh.
menu:
preview:
identifier: build-and-test
parent: core-database
weight: 2913
type: docs
---

`yb_build.sh` is a bash script for both building and testing.
Some flags can turn off certain parts of build, and other flags can decide which tests to run.
In general, they come down to these components:

- build:
- C++: C++ code in `src/yb/` and `ent/src/yb` for `yb-master`, `yb-tserver`, `yb-admin`, test binaries, etc.
- postgres: C code in `src/postgres/` for `postgres`, `ysql_dump`, `libyb_pgbackend`, `libpq`, etc.
- Java: Java code in `java/` for CDC, Java tests, drivers, etc.
- `initdb`: pre-created initial system catalog snapshot for YSQL
- test:
- C++ tests
- Java tests

For a full list of options, run `yb_build.sh -h`.
What follows are some of the common options to pay attention to.

## Build

### Targets

By default, all items are built.
You can specify a target to narrow down what to build.
See `./yb_build.sh -h` for the supported targets.
Besides that, certain flags may skip building some items.
For example, specifying a flag to run a C++ test skips the Java build (but running a Java test won't skip the C++ build).

Although there is some intelligence to avoid rebuilding parts, it is incomplete.
For example, the postgres build uses a build stamp calculated from a git commit and working changes; if there is a mismatch, it reruns postgres configure and make.
The Java build always runs the full build.
Use the `--skip-cxx-build`/`--scb` and `--skip-java-build`/`--sj` flags to reduce incremental build times.

`initdb` is a special case because it is only built if it hasn't been built before, but it isn't rebuilt again unless the `reinitdb` target is specified.
You should run `reinitdb` in case the initial system catalog in the source code is different since the last time `initdb` was run, unless you intentionally want to use the old initial system catalog (for example, to test upgrades).

### Build generator

CMake is used.

### Build tool

By default, `ninja` is used, but `make` is also supported.
Specify the build tool using the `--make` and `--ninja` flags.

### Build type

The following build types are available:

- debug (the default)
- release
- fastdebug: fewer compiler optimizations and a few other tweaks on debug
- asan: address sanitizer
- tsan: thread sanitizer

### Compiler

By default, `clang` is used, but `gcc` is also supported.

Specify the compiler using the `--gcc<version_number>` and `--clang<version_number>` flags.
The specific versions supported can be found in `./build-support/third-party-archives.yml`, which details the configurations regularly tested in-house.

### Third-party

By default, third-party libraries are pre-built into archives, and those archives are downloaded to be used during build.
Incremental builds currently do not detect when the third-party archive URL has been updated, so when that happens, you should run a `--clean` build to use the new third-party archive.
You can also build the third-party archives locally using `--no-download-thirdparty` or `--ndltp`.

## Test

The following examples use the `release` build type, but any build type can be specified, provided that build type is not disabled for that test.
For example, several tests are disabled for the `tsan` build type.

### C++ tests

By default, the `yb_build.sh` commands to run C++ tests will first build those tests.
Build can be avoided using `--skip-cxx-build` or `--scb`.

#### Run all tests

To run all the C++ tests, run the following command:

```sh
./yb_build.sh release --ctest
```

#### Run specific tests

To run a specific test, for example the `util_monotime-test` test, run the following command:

```sh
./yb_build.sh release --cxx-test util_monotime-test
```

To run a specific sub-test, for example the `TestMonoTime.TestCondition` sub-test in `util_monotime-test`, run the following command:

```sh
./yb_build.sh release --cxx-test util_monotime-test --gtest_filter TestMonoTime.TestCondition
```

`--gtest_filter` supports globbing.
For example, `TestMonoTime.TestTime*` runs both `TestMonoTime.TestTimeVal` and `TestMonoTime.TestTimeSpec`.
Make sure to escape or quote the `*` if your shell interprets it as a glob character.

### Java tests

By default, the `yb_build.sh` commands to run Java tests will first build key C++ targets and do the full Java build.
Build can be avoided using `--skip-cxx-build`/`--scb` and `--skip-java-build`/`--sj`.

#### Run all tests

To run all the Java tests, use the following command:

```sh
./yb_build.sh release --java-tests
```

#### Run specific tests

To run a specific test:

```sh
./yb_build.sh release --java-test org.yb.client.TestYBClient
```

To run a specific Java sub-test within a test file, use the # syntax.
For example:

```sh
./yb_build.sh release --java-test 'org.yb.client.TestYBClient#testClientCreateDestroy'
```

`--scb` and `--sj` are recommended in case the C++ and Java code was already built beforehand.

### Run tests multiple times

`yb_build.sh` has a built-in capability of running tests multiple times with parallelism.

- `--num_repetitions`/`-n`: number of times to run the test(s)
- `--test-parallelism`/`--tp`: number of instances of the test to run in parallel

Note that a high parallelism could result in failures if system resources are overused.

### Test frameworks

#### C++ (external) mini cluster

C++ tests are located in `src/yb` or `ent/src/yb` and end in `test.cc`.

Many C++ tests use external mini cluster or mini cluster to create clusters.
A key difference is that external mini clusters create separate master, tserver, and postgres processes (as in real life), while mini clusters create masters and tservers within the same process and optionally spawn a separate postgres process.
Use external mini clusters instead of mini clusters unless you have a specific reason to do otherwise, such as:

- you need access to catalog manager internals
- there is little to no YSQL usage and speed is more important

#### YSQL regress tests

YSQL Java tests are located in `java/yb-pgsql/src/test/java/org/yb/pgsql/`.

Some of those tests, named `TestPgRegress*`, use the PostgreSQL regress test framework (see `src/postgres/src/test/regress`).
They each correspond to a schedule (for example, `java/yb-pgsql/src/test/java/org/yb/pgsql/TestPgRegressArrays.java` references `src/postgres/src/test/regress/yb_arrays_schedule`) that is run by our modified version of `pg_regress`.
Each schedule lists a serial order of test files to run.
The same cluster is used for the whole schedule, but a new SQL connection is made for each test file.

The test framework does the following:

1. Copies test files from the `src` directory to the `build` directory (this is technically done as part of build).
1. Copies test files to a temporary `test` directory.
1. In the `test` directory, generates `sql`/`expected` from `input`/`output`
1. In the `test` directory, generates `results` by running tests in `sql`.
1. Copies back `results` from the `test` directory to the `build` directory.
1. Deletes the `test` directory.

The files in `results` are compared with those in `expected` to determine pass/fail.

{{< tip title="Tips" >}}

- To quickly run a specific SQL file, create a dummy Java file and dummy schedule with that one test in it.
- Use the following naming convention (some older files haven't adopted it yet, but should):
- `sql/foo.sql`: Unchanged from original PostgreSQL code.
- `sql/yb_foo.sql`: Completely new file (for example, with new features).
- `sql/yb_pg_foo.sql`: Modified version of original PostgreSQL foo.sql (for example, with compatibility edits).
The goal here is to reduce the difference between `foo.sql` and `yb_pg_foo.sql`, when possible.

{{< /tip >}}

### Test flags

The general hierarchy of flags is as follows:

1. Test framework: the framework may specify some default flags.
1. Test superclass: any parent classes of the test class can set flags.
1. Test subclass: child class flags should take precedence over parent class flags.
1. Test: a test itself may set flags.
1. User: the user running the test could add flags.

There may be some areas where the order of precedence is not followed: help fixing this is welcome.

Some of the ways in which you can specify flags to tests (uppercase are environment variables) are as follows:

- `YB_EXTRA_DAEMON_FLAGS`, `--extra-daemon-flags`, `--extra-daemon-args`: pass flags to master and tserver processes.
(This does not work on mini cluster.)
- `YB_EXTRA_MASTER_FLAGS`: pass flags to master processes.
(Does not work on mini cluster.)
- `YB_EXTRA_TSERVER_FLAGS`: pass flags to tserver processes.
(Does not work on mini cluster.)
- `--test-args`: for C++ tests, pass flags to the test process.
(For mini cluster, it also affects masters/tservers since they share the same process.)
- `YB_EXTRA_MVN_OPTIONS_IN_TESTS`, `--java-test-args`: for Java tests, pass flags in the form of Maven system parameters.

Here are some examples:

```sh
YB_EXTRA_DAEMON_FLAGS="--log_ysql_catalog_versions=true" \
YB_EXTRA_MASTER_FLAGS="--vmodule=master_heartbeat_service=2" \
YB_EXTRA_TSERVER_FLAGS="--vmodule=heartbeater=2" \
./yb_build.sh \
--cxx-test pgwrapper_pg_libpq-test \
--gtest_filter PgLibPqTest.DBCatalogVersion
```

```sh
./yb_build.sh \
--cxx-test integration-tests_master_failover-itest \
--gtest_filter MasterFailoverTest.DereferenceTasks \
--test-args "--vmodule=master_failover-itest=1,catalog_manager=4"
```

```sh
export YB_EXTRA_MVN_OPTIONS_IN_TESTS="-Dstyle.color=always"
./yb_build.sh \
--java-test TestPgRegressPgMisc \
--java-test-args "-Dyb.javatest.keepdata=true"
```
Original file line number Diff line number Diff line change
Expand Up @@ -87,9 +87,9 @@ There is no need to add any of those directories to `PATH`.

### Build release package

You can build a release package by executing:
Run the `yb_release` script to build a release package:

```shell
```output.sh
$ ./yb_release
......
2020-10-27 20:52:27,978 [yb_release.py:283 INFO] Generated a package at '/home/user/code/yugabyte-db/build/yugabyte-2.5.1.0-8696bc05a97c4907b53d6446b5bfa7acb28ceef5-release-centos-x86_64.tar.gz'
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,7 @@ brew install autoconf automake bash ccache cmake coreutils gnu-tar libtool \

{{< note title="Note" >}}

YugabyteDB build scripts rely on Bash 4. Make sure that `which bash` outputs `/usr/local/bin/bash` before proceeding. You may need to put `/usr/local/bin` as the first directory on `PATH` in your `~/.bashrc` to achieve that.
YugabyteDB build scripts require at least Bash version 4. Make sure that `bash --version` outputs a version of 4 or higher before proceeding. You may need to put `/usr/local/bin` (Intel) or `/opt/homebrew/bin` (Apple Silicon) as the first directory on `PATH` in your `~/.bashrc` to achieve that.

{{< /note >}}

Expand All @@ -78,9 +78,9 @@ YugabyteDB build scripts rely on Bash 4. Make sure that `which bash` outputs `/u

### Build release package

You can build a release package by executing:
Run the `yb_release` script to build a release package:

```shell
```output.sh
$ ./yb_release
......
2020-10-27 13:55:40,856 [yb_release.py:283 INFO] Generated a package at '/Users/me/code/yugabyte-db/build/yugabyte-2.5.1.0-6ab8013159fdca00ced7e6f5d2f98cacac6a536a-release-darwin-x86_64.tar.gz'
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -83,4 +83,4 @@ sudo locale-gen en_US.UTF-8

### Build release package

Currently a release package can only be built in [CentOS](../build-from-src-centos) & [MacOS](../build-from-src-macos).
Currently, you can only build release packages in [CentOS](../build-from-src-centos) and [macOS](../build-from-src-macos).
2 changes: 1 addition & 1 deletion docs/content/preview/contribute/core-database/checklist.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ type: docs
```

* Next, [build the source code](../build-from-src).
* Optionally, you may want to [run the unit tests](../run-unit-tests).
* Optionally, you may want to [run the unit tests](../build-and-test#test).

## Step 2. Start a local cluster

Expand Down
Original file line number Diff line number Diff line change
@@ -1,3 +1,9 @@
<!--
+++
private = true
+++
-->

Assuming [this repository][repo] is checked out in `~/code/yugabyte-db`, do the following:

```sh
Expand All @@ -14,4 +20,7 @@ Try again by running the build script with less concurrency, for example, `-j1`.

{{< /note >}}

For more details about building and testing, refer to [Build and test][build-and-test].

[repo]: https://github.com/yugabyte/yugabyte-db
[build-and-test]: ../build-and-test
Original file line number Diff line number Diff line change
@@ -1,3 +1,9 @@
<!--
+++
private = true
+++
-->

YugabyteDB core is written in C and C++, but the repository contains Java code needed to run some tests and sample applications. To build the Java part, you need:

* Java Development Kit (JDK) 1.8. JDK installers for Linux and macOS can be downloaded from [OpenJDK](http://jdk.java.net/), [AdoptOpenJDK](https://adoptopenjdk.net/), or [Azul Systems](https://www.azul.com/downloads/zulu-community/). Homebrew users on macOS can install using `brew install openjdk`.
Expand Down
Loading

0 comments on commit 6ab3904

Please sign in to comment.