chore: add production profile for version release & add developer docs

Cargo.toml

@@ -282,17 +282,22 @@ private_intra_doc_links = "allow"
 # Explicit lints don't hurt, and sometimes rust-analyzer works better with explicit links.
 redundant_explicit_links = "allow"
 
+# Tweak built-in profiles and define custom profiles.
+# See `docs/dev/src/build-and-run/profiles.md` for detailed information.
 [profile.dev]
-lto = 'off'
+lto = "off"
 
 [profile.release]
 debug = "full"
+incremental = true
 split-debuginfo = "packed"
+lto = "off"
+
+[profile.production]
+inherits = "release"
+incremental = false
 lto = "thin"
 
-# The profile used for CI in main branch.
-# This profile inherits from the release profile, but turns on some checks and assertions for us to
-# better catch bugs in CI.
 [profile.ci-release]
 inherits = "release"
 incremental = false
@@ -302,9 +307,6 @@ split-debuginfo = "off"
 debug-assertions = true
 overflow-checks = true
 
-# The profile used for CI in pull requests.
-# External dependencies are built with optimization enabled, while crates in this workspace are built
-# with `dev` profile and full debug info. This is a trade-off between build time and e2e test time.
 [profile.ci-dev]
 inherits = "dev"
 incremental = false
@@ -318,14 +320,11 @@ opt-level = 3
 [profile.ci-dev.package."indextree"]
 opt-level = 3
 
-# The profile used for deterministic simulation tests in CI.
-# The simulator can only run single-threaded, so optimization is required to make the running time
-# reasonable. The optimization level is customized to speed up the build.
 [profile.ci-sim]
 inherits = "dev"
-opt-level = 2
 incremental = false
-debug = 1
+debug = "line-tables-only"
+opt-level = 2
 
 [patch.crates-io]
 # Patch third-party crates for deterministic simulation.

ci/scripts/release.sh

@@ -71,9 +71,9 @@ if [ "${ARCH}" == "aarch64" ]; then
   # see https://github.com/tikv/jemallocator/blob/802969384ae0c581255f3375ee2ba774c8d2a754/jemalloc-sys/build.rs#L218
   export JEMALLOC_SYS_WITH_LG_PAGE=16
 fi
-OPENSSL_STATIC=1 cargo build -p risingwave_cmd_all --features "rw-static-link" --features external-udf --features wasm-udf --features js-udf --profile release
-OPENSSL_STATIC=1 cargo build -p risingwave_cmd --bin risectl --features "rw-static-link" --profile release
-cd target/release && chmod +x risingwave risectl
+OPENSSL_STATIC=1 cargo build -p risingwave_cmd_all --features "rw-static-link" --features external-udf --features wasm-udf --features js-udf --profile production
+OPENSSL_STATIC=1 cargo build -p risingwave_cmd --bin risectl --features "rw-static-link" --profile production
+cd target/production && chmod +x risingwave risectl
 
 echo "--- Upload nightly binary to s3"
 if [ "${BUILDKITE_SOURCE}" == "schedule" ]; then
@@ -90,7 +90,7 @@ cd "${REPO_ROOT}"/java && mvn -B package -Dmaven.test.skip=true -Dno-build-rust
 if [[ -n "${BUILDKITE_TAG}" ]]; then
   echo "--- Collect all release assets"
   cd "${REPO_ROOT}" && mkdir release-assets && cd release-assets
-  cp -r "${REPO_ROOT}"/target/release/* .
+  cp -r "${REPO_ROOT}"/target/production/* .
   mv "${REPO_ROOT}"/java/connector-node/assembly/target/risingwave-connector-1.0.0.tar.gz risingwave-connector-"${BUILDKITE_TAG}".tar.gz
   tar -zxvf risingwave-connector-"${BUILDKITE_TAG}".tar.gz libs
   ls -l

docker/Dockerfile

@@ -55,7 +55,7 @@ RUN cargo install flamegraph
 # COPY --from=rust-planner /risingwave/recipe.json recipe.json
 
 # # Build dependencies - this can be cached if the dependencies don't change
-# RUN cargo chef cook --release --recipe-path recipe.json
+# RUN cargo chef cook --profile production --recipe-path recipe.json
 
 FROM rust-base AS rust-builder
 
@@ -70,11 +70,11 @@ ENV ENABLE_BUILD_DASHBOARD=1
 ENV OPENSSL_STATIC=1
 
 RUN cargo fetch && \
-  cargo build -p risingwave_cmd_all --release --features "rw-static-link" --features all-udf && \
+  cargo build -p risingwave_cmd_all --profile production --features "rw-static-link" --features all-udf && \
   mkdir -p /risingwave/bin && \
-    mv /risingwave/target/release/risingwave /risingwave/bin/ && \
-    mv /risingwave/target/release/risingwave.dwp /risingwave/bin/ && \
-  cp ./target/release/build/tikv-jemalloc-sys-*/out/build/bin/jeprof /risingwave/bin/ && \
+    mv /risingwave/target/production/risingwave /risingwave/bin/ && \
+    mv /risingwave/target/production/risingwave.dwp /risingwave/bin/ && \
+  cp ./target/production/build/tikv-jemalloc-sys-*/out/build/bin/jeprof /risingwave/bin/ && \
   chmod +x /risingwave/bin/jeprof && \
   mkdir -p /risingwave/lib && cargo clean
 

docker/Dockerfile.hdfs

@@ -1,3 +1,5 @@
+# FIXME: this file is not well maintained compared to the main Dockerfile and may not work as expected.
+
 FROM ubuntu:24.04 AS base
 
 ENV LANG en_US.utf8
@@ -102,15 +104,15 @@ ENV OPENSSL_STATIC=1
 RUN cargo fetch && \
   cargo build -p risingwave_cmd_all --release -p risingwave_object_store --features hdfs-backend --features "rw-static-link" --features all-udf && \
   mkdir -p /risingwave/bin && \
-    mv /risingwave/target/release/risingwave /risingwave/bin/ && \
-    mv /risingwave/target/release/risingwave.dwp /risingwave/bin/ && \
+  mv /risingwave/target/release/risingwave /risingwave/bin/ && \
+  mv /risingwave/target/release/risingwave.dwp /risingwave/bin/ && \
   cp ./target/release/build/tikv-jemalloc-sys-*/out/build/bin/jeprof /risingwave/bin/ && \
   chmod +x /risingwave/bin/jeprof && \
   mkdir -p /risingwave/lib && cargo clean
 
 RUN cd /risingwave/java && mvn -B package -Dmaven.test.skip=true -Dno-build-rust && \
-    mkdir -p /risingwave/bin/connector-node && \
-    tar -zxvf /risingwave/java/connector-node/assembly/target/risingwave-connector-1.0.0.tar.gz -C /risingwave/bin/connector-node
+  mkdir -p /risingwave/bin/connector-node && \
+  tar -zxvf /risingwave/java/connector-node/assembly/target/risingwave-connector-1.0.0.tar.gz -C /risingwave/bin/connector-node
 
 FROM ubuntu:24.04 as image-base
 RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get -y install ca-certificates openjdk-17-jdk wget libsasl2-dev && rm -rf /var/lib/{apt,dpkg,cache,log}/

docker/aws/aws-build.sh

@@ -1,5 +1,7 @@
 #!/usr/bin/env bash
 
+# FIXME: this script has not been maintained for a long time.
+
 set -e
 
 export DOCKER_BUILDKIT=1

docs/dev/src/SUMMARY.md

@@ -8,6 +8,7 @@
 # Building and debugging RisingWave
 
 - [Building and Running](./build-and-run/intro.md)
+    - [Profiles](./build-and-run/profiles.md)
 - [Testing](./tests/intro.md)
 - [Debugging](./debugging.md)
 - [Observability](./observability.md)

docs/dev/src/build-and-run/profiles.md

@@ -0,0 +1,70 @@
+# Build Profiles
+
+RisingWave uses Cargo profiles to manage build settings. To briefly introduce Cargo profiles, here is a snippet from the [Cargo References](https://doc.rust-lang.org/cargo/reference/profiles.html):
+
+> Profiles provide a way to alter the compiler settings, influencing things like optimizations and debugging symbols.
+>
+> Cargo has 4 built-in profiles: `dev`, `release`, `test`, and `bench`. The profile is automatically chosen based on which command is being run if a profile is not specified on the command-line. In addition to the built-in profiles, custom user-defined profiles can also be specified.
+
+All profiles talked in this document are defined in the `Cargo.toml` file of the root directory of the project. Please always refer to it for the most up-to-date information.
+
+## Built-in Profiles
+
+RisingWave tweaks some settings of the built-in profiles to better fit its needs, in the sections of `[profile.<built-in-profile>]` in `Cargo.toml`. For example,
+
+- `dev`: for local development and testing
+
+  - completely disables [LTO](https://doc.rust-lang.org/cargo/reference/profiles.html#lto) to speed up the build time
+
+- `release`: for local testing with near-production performance
+
+  - completely disables LTO to speed up the build time
+  - embeds full debug information to help with debugging in production
+
+## Custom Profiles
+
+RisingWave also defines some custom profiles that inherit from the built-in profiles, in the sections of `[profile.<custom-profile>]` in `Cargo.toml`. For example,
+
+- `production`: for distribution and production deployment
+
+  - inherits from `release`
+  - enables aggressive code optimizations (like LTO) for maximum performance, at the cost of significantly increased build time
+
+- `ci-dev`: for `pull-request` pipelines in CI
+
+  - inherits from `dev`
+  - tweaks some settings to reduce the build time and binary size
+  - enables code optimizations for 3rd-party dependencies to improve CI performance
+
+- `ci-release`: for `main` and `main-cron` pipelines in CI
+
+  - inherits from `release`
+  - tweaks some settings to reduce the build time and binary size
+  - enables more runtime checks (like debug assertions and overflow checks) to catch potential bugs
+
+- `ci-sim`: for `madsim` simulation tests in CI
+  - similar to `ci-dev`
+  - enables slight code optimizations for all crates to improve CI performance under single-threaded madsim execution
+
+## Comparisons
+
+To give a better idea of the differences between the profiles, here is a matrix comparing the profiles:
+
+| Profile      | Debug Info     | `cfg(debug_assertions)` | Performance | Build Time |
+| ------------ | -------------- | ----------------------- | ----------- | ---------- |
+| `dev`        | Full           | `true`                  | Bad         | Fastest    |
+| `release`    | Full           | `false`                 | Good        | Slow       |
+| `production` | Full           | `false`                 | Best        | Slowest    |
+| `ci-dev`     | Backtrace only | `true`                  | Medium      | Fast       |
+| `ci-release` | Backtrace only | `true`                  | Good        | Slow       |
+| `ci-sim`     | Backtrace only | `true`                  | Medium      | Medium     |
+
+Some miscellaneous notes:
+
+- Compared to "Backtrace only", "Full" debug information additionally includes the capability to attach a debugger at runtime or on core dumps, to inspect variables and stack traces.
+- There are also other subtle differences like incremental compilation settings, overflow checks, and more. They are not listed here for brevity.
+- `cfg(debug_assertions)` can be roughly used to determine whether it's a production environment or not. Note that even though `ci-release` contains `release` in its name, the `debug_assertions` are still enabled.
+
+## Choose a Profile
+
+By default, RisingWave (and RiseDev) uses the `dev` profile for local development and testing. To use `release` profile instead, you can set the corresponding configuration entry by running `risedev configure`. Other profiles are for their specific use cases and are not meant to be used directly by developers, thus not available with RiseDev.