This is an automated email from the ASF dual-hosted git repository.
philo-he pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/gluten.git
The following commit(s) were added to refs/heads/main by this push:
new 57a167adf7 [VL] Use the dynamic-link image for the dev container
(#12778)
57a167adf7 is described below
commit 57a167adf7f5422e1cca458cf11b9aa65dc62d74
Author: Felipe Pessoto <[email protected]>
AuthorDate: Fri Aug 21 17:36:04 2026 -0700
[VL] Use the dynamic-link image for the dev container (#12778)
---
.devcontainer/devcontainer.json | 78 +++++++++++-
.devcontainer/post-create.sh | 148 ++++++++++++++++++++++
docs/developers/dev-container.md | 261 +++++++++++++++++++++++++--------------
3 files changed, 389 insertions(+), 98 deletions(-)
diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json
index 342f94f678..81b75291cd 100644
--- a/.devcontainer/devcontainer.json
+++ b/.devcontainer/devcontainer.json
@@ -1,5 +1,77 @@
+// Dev Container for the Gluten Velox backend.
+// See docs/developers/dev-container.md for the rationale behind these settings
+// and for the build commands to run once the container is up.
{
- "name": "Gluten Velox Backend (vcpkg-centos-9, static link)",
- "image": "apache/gluten:vcpkg-centos-9",
- "postCreateCommand": "./dev/ci-velox-buildstatic-centos-9.sh"
+ "name": "Gluten Velox Backend (centos-9, dynamic link)",
+
+ // Ships Velox's dependencies and Arrow under /usr/local, a pre-warmed
Maven
+ // repository, and the Spark distributions gluten-ut needs under
/opt/shims.
+ "image": "apache/gluten:centos-9-jdk8",
+
+ // Codespaces only. Storage is the binding constraint: a 32 GB disk cannot
+ // hold the image plus the Velox build tree.
+ "hostRequirements": {
+ "cpus": 4,
+ "memory": "16gb",
+ "storage": "64gb"
+ },
+
+ "containerEnv": {
+ "CCACHE_DIR": "/root/.ccache",
+ "CCACHE_MAXSIZE": "10G",
+ // folly, gflags and glog are shared libraries in this image; a Velox
+ // dependency build that disagrees fails to link.
+ "VELOX_BUILD_SHARED": "ON"
+ },
+
+ // What /opt/rh/gcc-toolset-12/enable exports. The image's default GCC 11
+ // cannot compile Velox's C++20 sources, and the build scripts do not
enable
+ // the toolset themselves. Keep in sync with that script.
+ "remoteEnv": {
+ "PATH": "/opt/rh/gcc-toolset-12/root/usr/bin:${containerEnv:PATH}",
+ "LD_LIBRARY_PATH":
"/opt/rh/gcc-toolset-12/root/usr/lib64:/opt/rh/gcc-toolset-12/root/usr/lib",
+ "PKG_CONFIG_PATH": "/opt/rh/gcc-toolset-12/root/usr/lib64/pkgconfig"
+ },
+
+ // Survive "Rebuild Container". Docker seeds a new named volume from the
+ // image, so the Maven repository it ships is kept, not hidden.
+ "mounts": [
+ "source=gluten-ccache,target=/root/.ccache,type=volume",
+ "source=gluten-m2,target=/root/.m2,type=volume"
+ ],
+
+ // Prepares the environment only; see post-create.sh for why it never
builds.
+ "postCreateCommand": "bash .devcontainer/post-create.sh",
+
+ "customizations": {
+ "vscode": {
+ "extensions": [
+ "scalameta.metals",
+ "ms-vscode.cpptools",
+ "ms-python.python"
+ ],
+ "settings": {
+ // A build leaves >10 GB in the workspace; watching it exhausts
+ // inotify handles.
+ "files.watcherExclude": {
+ "**/target/**": true,
+ "**/cpp/build/**": true,
+ "**/ep/_ep/**": true,
+ "**/ep/build-velox/build/**": true,
+ "**/dev/vcpkg/.vcpkg/**": true,
+ "**/dev/vcpkg/vcpkg_installed/**": true
+ },
+ "search.exclude": {
+ "**/target/**": true,
+ "**/cpp/build/**": true,
+ "**/ep/_ep/**": true,
+ "**/ep/build-velox/build/**": true,
+ "**/dev/vcpkg/.vcpkg/**": true,
+ "**/dev/vcpkg/vcpkg_installed/**": true
+ },
+ // Written by the native build
(-DCMAKE_EXPORT_COMPILE_COMMANDS=ON).
+ "C_Cpp.default.compileCommands":
"${workspaceFolder}/cpp/build/compile_commands.json"
+ }
+ }
+ }
}
diff --git a/.devcontainer/post-create.sh b/.devcontainer/post-create.sh
new file mode 100755
index 0000000000..6ca6215872
--- /dev/null
+++ b/.devcontainer/post-create.sh
@@ -0,0 +1,148 @@
+#!/usr/bin/env bash
+
+# Licensed to the Apache Software Foundation (ASF) under one or more
+# contributor license agreements. See the NOTICE file distributed with
+# this work for additional information regarding copyright ownership.
+# The ASF licenses this file to You under the Apache License, Version 2.0
+# (the "License"); you may not use this file except in compliance with
+# the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+# Dev Container postCreateCommand.
+#
+# This only prepares the environment; it never builds Velox. A Velox build
takes
+# tens of minutes to several hours, and a postCreateCommand that long stalls
+# container creation and leaves a half-built tree behind when the editor
+# disconnects or Codespaces times out. Run the build yourself once the
container
+# is up -- the command is printed at the end of this script.
+
+set -uo pipefail
+
+NUM_THREADS_MARKER='# >>> gluten dev container num_threads >>>'
+
+warn() { echo "WARNING: $*" >&2; }
+
+echo "Preparing the Gluten dev container..."
+
+# Spark 4.0/4.1 and the UDF tests need JDK 17, which this JDK 8 image lacks.
+# Both JDKs can coexist: JAVA_HOME still points at JDK 8 for the default build.
+if [ ! -d /usr/lib/jvm/java-17-openjdk ]; then
+ echo "Installing JDK 17 alongside JDK 8 (needed for Spark 4.x)..."
+ dnf install -y --setopt=install_weak_deps=False java-17-openjdk-devel
>/dev/null ||
+ warn "could not install JDK 17; Spark 4.x builds will not work until
it is installed."
+fi
+
+# The clang-format and regex installs below need pip3, which the image gets
+# transitively rather than by an explicit install.
+if ! command -v pip3 >/dev/null 2>&1; then
+ echo "Installing python3-pip..."
+ dnf install -y --setopt=install_weak_deps=False python3-pip >/dev/null ||
+ warn "could not install python3-pip; clang-format 15 and regex will be
missing."
+fi
+
+# dev/format-cpp-code.sh requires a binary literally named clang-format-15, and
+# tries to install it with apt, which does not exist on CentOS.
+if ! command -v clang-format-15 >/dev/null 2>&1; then
+ echo "Installing clang-format 15..."
+ if pip3 install --quiet --retries 1 clang-format==15.0.7; then
+ CLANG_FORMAT=$(command -v clang-format)
+ if [ -n "$CLANG_FORMAT" ]; then
+ ln -sf "$CLANG_FORMAT" /usr/local/bin/clang-format-15
+ fi
+ else
+ warn "could not install clang-format 15; ./dev/format-cpp-code.sh will
not run."
+ fi
+fi
+
+# dev/check.py and .github/workflows/util/license-header.py import regex.
+if ! python3 -c "import regex" >/dev/null 2>&1; then
+ echo "Installing the regex module..."
+ pip3 install --quiet --retries 1 regex ||
+ warn "could not install the regex module; ./dev/check.py will not run."
+fi
+
+# Cap build parallelism by memory, not just by core count.
+# dev/builddeps-veloxbe.sh defaults NUM_THREADS to "nproc --ignore=2", which
+# ignores memory entirely. Velox's heavier translation units peak at roughly
+# 3.5 GB of resident memory each, so on a machine with many cores relative to
+# its RAM the default oversubscribes memory badly: on 32 cores / 62 GB it asks
+# for 30 jobs, about 100 GB, and the OOM killer takes down the build or the
+# whole container. Reserve a few GB for the editor, Maven and the OS, allow
+# about 4 GB per job, and never exceed the CPU-based default.
+#
+# Installed as a command and re-run per shell below, so the value follows the
+# machine: a Codespace can be resized without postCreateCommand running again.
+cat >/usr/local/bin/gluten-num-threads <<'HELPER'
+#!/usr/bin/env bash
+# Build parallelism for Velox: ~4 GB per compile job, capped by core count.
+cpu=$(nproc --ignore=2)
+mem=$(awk '/^MemTotal:/ {print int(($2 / 1048576 - 8) / 4)}' /proc/meminfo)
+[ "${cpu:-0}" -lt 1 ] && cpu=1
+[ "${mem:-0}" -lt 1 ] && mem=1
+[ "$mem" -lt "$cpu" ] && echo "$mem" || echo "$cpu"
+HELPER
+chmod +x /usr/local/bin/gluten-num-threads
+
+# Export it so a plain "./dev/buildbundle-veloxbe.sh", as documented in
+# docs/get-started/Velox.md, is memory-safe too and not just the command
printed
+# below.
+if ! grep -qF "$NUM_THREADS_MARKER" "$HOME/.bashrc" 2>/dev/null; then
+ cat >>"$HOME/.bashrc" <<EOF
+
+$NUM_THREADS_MARKER
+# Velox compiles need ~4 GB per job; the build scripts size NUM_THREADS from
the
+# core count alone, which the OOM killer punishes on core-rich machines.
+export NUM_THREADS=\${NUM_THREADS:-\$(gluten-num-threads)}
+# <<< gluten dev container num_threads <<<
+EOF
+fi
+
+NUM_THREADS=$(/usr/local/bin/gluten-num-threads)
+CPU_THREADS=$(nproc --ignore=2)
+MEM_GB=$(awk '/^MemTotal:/ {printf "%d", $2 / 1048576}' /proc/meminfo
2>/dev/null)
+
+cat <<EOF
+
+============================================================================
+Gluten dev container is ready. The native build has NOT been run.
+
+Build the Velox backend and install the Gluten jars:
+
+ ./dev/buildbundle-veloxbe.sh --run_setup_script=OFF --build_arrow=OFF \\
+ --build_tests=ON --spark_version=3.5
+
+ --run_setup_script=OFF dependencies are already installed in this image
+ --build_arrow=OFF Arrow is already installed under /usr/local
+ --build_tests=ON also build the C++ unit tests (drop it to build
faster)
+ --spark_version=3.5 build one Spark version instead of all five
+
+NUM_THREADS=${NUM_THREADS} is exported for you, sized from this machine's
${MEM_GB:-?} GB at
+~4 GB per compile job. The build scripts would take $CPU_THREADS from the core
count
+alone, which invites the OOM killer. VS Code tasks do not read ~/.bashrc, so
pass
+--num_threads=${NUM_THREADS} there.
+
+After changing C++ code, rebuild just the native side (drop build_velox when
only
+Gluten's own C++ under cpp/ changed):
+
+ ./dev/builddeps-veloxbe.sh --run_setup_script=OFF --build_arrow=OFF \\
+ --build_tests=ON build_velox build_gluten_cpp
+
+Run a Spark unit test suite (Spark distributions are pre-installed in this
image;
+CI runs these on JDK 17, and without -DwildcardSuites the whole suite runs for
+hours):
+
+ export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
+ ./build/mvn test -Pspark-ut -Pbackends-velox -Pspark-3.5 -Pjava-17 \\
+ -DargLine="-Dspark.test.home=/opt/shims/spark35/spark_home/" \\
+ -DwildcardSuites=org.apache.spark.sql.GlutenSQLQuerySuite
+
+See docs/developers/dev-container.md for details.
+============================================================================
+EOF
diff --git a/docs/developers/dev-container.md b/docs/developers/dev-container.md
index 25a2f47077..d4346533d9 100644
--- a/docs/developers/dev-container.md
+++ b/docs/developers/dev-container.md
@@ -1,95 +1,166 @@
----
-layout: page
-title: Dev Container
-nav_order: 18
-parent: Developer Overview
----
-
-# Develop Gluten in a Dev Container
-
-Gluten ships a [Dev Container](https://containers.dev/) configuration at
-[`.devcontainer/devcontainer.json`](https://github.com/apache/gluten/blob/main/.devcontainer/devcontainer.json)
-so you can develop inside a pre-built Docker image with the Velox/Gluten native
-toolchain already installed. This is the fastest way to get a working Gluten
build
-without manually installing JDK, Maven, GCC, vcpkg, and the rest of the native
-dependencies on your host.
-
-## What the default configuration does
-
-The default configuration opens the workspace inside
`apache/gluten:vcpkg-centos-9`
-(static link, CentOS 9, GCC toolset 12) and runs
-`./dev/ci-velox-buildstatic-centos-9.sh` as its `postCreateCommand` to perform
the
-initial native Velox + Gluten C++ build with vcpkg. After the post-create step
-finishes, the container is ready for a Maven build (for example,
-`mvn package -Pbackends-velox -DskipTests`).
-
-## Prerequisites
-
-- [Docker](https://docs.docker.com/get-docker/) (or any other OCI runtime
supported by
- your editor) installed and running on the host, **or** a GitHub
Codespaces-enabled
- account.
-- Either:
- - [Visual Studio Code](https://code.visualstudio.com/) with the
- [Dev Containers
extension](https://code.visualstudio.com/docs/devcontainers/containers),
- or
- - [GitHub Codespaces](https://docs.github.com/en/codespaces) (the
- `.devcontainer/devcontainer.json` is picked up automatically when you
create a
- Codespace for the repository).
-
-## Open the workspace in a Dev Container
-
-In VS Code:
-
-1. Open the cloned Gluten repository.
-2. Run the **Dev Containers: Reopen in Container** command from the Command
Palette
- (`F1`).
-3. Wait for the image to be pulled and the `postCreateCommand` to finish. The
first
- run includes the native build and can take a while depending on your
machine.
-
-In Codespaces, just create a new Codespace for the repository -- the same flow
is
-executed in the cloud.
-
-## Available images
-
-The default `apache/gluten:vcpkg-centos-9` is only one of several pre-built
images
-maintained by the Gluten community. Other images are available as well -- see
the
-full list at
-[https://hub.docker.com/r/apache/gluten/tags](https://hub.docker.com/r/apache/gluten/tags).
-
-The Dockerfiles that produce these images, and a summary of what each one is
intended
-for (CentOS 8/9, static vs. dynamic link, different JDK versions, CUDF, etc.),
are
-documented in [Velox Backend CI](./velox-backend-CI.md#docker-build).
-
-## Customize the configuration
-
-To use a different image -- for example a dynamically linked CentOS 8 image
with
-JDK 17 -- edit `.devcontainer/devcontainer.json` and update the `image` field,
and
-the `postCreateCommand` if the toolchain provided by the new image requires a
-different build script:
-
-```jsonc
-{
- "name": "Gluten Velox Backend (centos-8-jdk17, dynamic link)",
- "image": "apache/gluten:centos-8-jdk17",
- "postCreateCommand": "./dev/builddeps-veloxbe.sh --run_setup_script=ON
--enable_vcpkg=OFF --build_arrow=OFF"
-}
-```
-
-You can also drop the `postCreateCommand` entirely if you prefer to run the
native
-build manually inside the container; see
-[Build Gluten Velox backend in docker](./velox-backend-build-in-docker.md) for
the
-full set of build flags and the trade-offs between static and dynamic linking.
-
-## Use the image without a Dev Container
-
-The same images can be used directly with `docker run` if you do not want to
use the
-Dev Containers tooling:
-
-```bash
-docker run -it --rm -v "$PWD":/workspace -w /workspace
apache/gluten:vcpkg-centos-9 bash
-# then, inside the container:
-./dev/ci-velox-buildstatic-centos-9.sh
-```
-
-See [Build Gluten Velox backend in docker](./velox-backend-build-in-docker.md)
for
-more involved build recipes (packaging the Gluten jar, dynamic-link builds,
etc.).
+---
+layout: page
+title: Dev Container
+nav_order: 18
+parent: Developer Overview
+---
+
+# Develop Gluten in a Dev Container
+
+Gluten ships a [Dev Container](https://containers.dev/) configuration at
+[`.devcontainer/devcontainer.json`](https://github.com/apache/gluten/blob/main/.devcontainer/devcontainer.json),
+so you can develop inside a pre-built image that already has the JDK, Maven,
GCC
+toolset and the whole Velox native dependency stack installed.
+
+## Prerequisites
+
+[Docker](https://docs.docker.com/get-docker/) plus
+[VS Code](https://code.visualstudio.com/) with the
+[Dev Containers
extension](https://code.visualstudio.com/docs/devcontainers/containers),
+or a [Codespaces](https://docs.github.com/en/codespaces)-enabled account.
+
+## Open the workspace
+
+In VS Code, run **Dev Containers: Reopen in Container** from the Command
Palette
+(`F1`). In Codespaces, create a Codespace for the repository.
+
+## What the configuration does
+
+It opens the workspace in `apache/gluten:centos-9-jdk8` (CentOS Stream 9, JDK
8,
+**dynamically linked** dependencies), puts GCC 12 on `PATH` through `remoteEnv`
+because the default GCC 11 cannot compile Velox's C++20 sources, and runs
+[`.devcontainer/post-create.sh`](https://github.com/apache/gluten/blob/main/.devcontainer/post-create.sh),
+which installs JDK 17, `clang-format` 15 and the `regex` module, sizes
`NUM_THREADS`
+for the machine and prints the build commands.
+
+**The native build is not run automatically.** It takes tens of minutes to
several
+hours, which would stall container creation and leave a half-built tree behind
+whenever the editor disconnects or a Codespace times out.
+
+## Build Gluten
+
+```bash
+./dev/buildbundle-veloxbe.sh --run_setup_script=OFF --build_arrow=OFF \
+ --build_tests=ON --spark_version=3.5
+```
+
+| Flag | Why |
+|---|---|
+| `--run_setup_script=OFF` | Velox's third-party libraries are already
installed in the image; `ON` rebuilds them all from source into `/usr/local`. |
+| `--build_arrow=OFF` | Arrow is already installed under `/usr/local` and its
jars are in `~/.m2`. |
+| `--build_tests=ON` | Also builds the C++ unit tests. Drop it if you only
need the jars. |
+| `--spark_version=3.5` | The default, `ALL`, runs five full Maven builds
(Spark 3.3 to 4.1). |
+
+To rebuild only the native side after a C++ change:
+
+```bash
+./dev/builddeps-veloxbe.sh --run_setup_script=OFF --build_arrow=OFF \
+ --build_tests=ON build_velox build_gluten_cpp
+```
+
+Drop `build_velox` when only Gluten's own C++ under `cpp/` changed. Keep
+`--build_tests` matched with the flag you built with: `build_gluten_cpp` wipes
+`cpp/build` on every run, so omitting it silently drops the C++ test binaries.
+
+Spark 4.0/4.1 need JDK 17 and Scala 2.13. `buildbundle-veloxbe.sh` adds the
Maven
+profiles, but `JAVA_HOME` is yours to set:
+
+```bash
+export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
+./dev/buildbundle-veloxbe.sh --run_setup_script=OFF --build_arrow=OFF
--spark_version=4.0
+```
+
+### Build parallelism and the OOM killer
+
+`builddeps-veloxbe.sh` sizes `NUM_THREADS` as `nproc --ignore=2`, ignoring
memory,
+while Velox's heavier translation units peak at ~3.5 GB resident each. On a
32-core,
+62 GB container that is 30 jobs asking for roughly 100 GB, and the OOM killer
takes
+down the build or the container. `post-create.sh` therefore exports a value
allowing
+~4 GB per job — 13 jobs on that machine, measured at a 41 GB peak.
+
+An explicit `export NUM_THREADS=<n>` still wins. VS Code tasks do not read
+`~/.bashrc`, so pass `--num_threads=<n>` there.
+
+## Run the tests
+
+The image unpacks a Spark distribution for every supported version under
`/opt/shims`,
+which is what `spark.test.home` needs. CI runs the Spark 3.3/3.4/3.5 unit
tests on
+JDK 17:
+
+```bash
+export JAVA_HOME=/usr/lib/jvm/java-17-openjdk
+./build/mvn test -Pspark-ut -Pbackends-velox -Pspark-3.5 -Pjava-17 \
+ -DargLine="-Dspark.test.home=/opt/shims/spark35/spark_home/" \
+ -DwildcardSuites=org.apache.spark.sql.GlutenSQLQuerySuite
+```
+
+`-DwildcardSuites` takes a fully qualified class name and keeps a run to
minutes;
+without it the whole suite runs for hours. Do not add `-pl gluten-ut`: it is an
+aggregator POM, `-pl` does not pull in its children, and the build finishes in
seconds
+having run nothing. See [HowTo](./HowTo.md#3-how-to-debug-javascala) for more.
+
+C++ unit tests (requires `--build_tests=ON`):
+
+```bash
+cd cpp/build && ctest -V
+```
+
+## Static or dynamic link?
+
+"Dynamic" and "static" describe **how third-party dependencies are linked**.
Velox
+itself is archived into `libvelox.a` and linked into Gluten's shared libraries
either
+way, so `VELOX_BUILD_SHARED` only controls whether folly, gflags and glog are
built
+shared; `devcontainer.json` sets it to `ON` to match the image.
+
+| | Dynamic (`--enable_vcpkg=OFF`, the default) | Static (`--enable_vcpkg=ON`)
|
+|---|---|---|
+| Image | `apache/gluten:centos-9-jdk8` | `apache/gluten:vcpkg-centos-9` |
+| Dependencies | Pre-installed system libraries | vcpkg ports |
+| Spark distributions | `/opt/shims`, so `gluten-ut` runs | Not installed |
+| JDK | 8, with 17 added by `post-create.sh` | 17 only |
+| Resulting jar | Needs the same shared libraries | Runs on any x86-64 Linux |
+
+Static linking exists to produce **portable release jars**, which is worth
paying for
+in CI and releases but buys a developer nothing, since the jar never leaves the
+container. The vcpkg image also lacks `/opt/shims`, so the Spark unit tests
cannot
+run in it at all.
+
+vcpkg itself caches well: `apache/gluten:vcpkg-centos-9` bakes in
+`VCPKG_BINARY_SOURCES=clear;files,/var/cache/vcpkg,readwrite`, and because the
ABI
+hash is computed per port, a checkout that has moved rebuilds only the ports it
+actually changed plus their dependents. Be aware that the ABI hash also covers
the
+toolchain, so a change of compiler or triplet invalidates every port at once,
and
+vcpkg does not explain why it started rebuilding.
+
+To reproduce a static-link problem, switch `image` to
`apache/gluten:vcpkg-centos-9`
+and build with `./dev/ci-velox-buildstatic-centos-9.sh` (it exports
`NUM_THREADS=2`
+for CI runners; raise it first). Build trees are tied to the image that
produced
+them — `cpp/build/CMakeCache.txt` records the vcpkg toolchain and
+`ep/build-velox/build/velox_ep/_build/` records `VELOX_BUILD_SHARED` — so wipe
them
+when switching:
+
+```bash
+rm -rf cpp/build ep/build-velox/build/velox_ep/_build ep/_ep \
+ dev/vcpkg/.vcpkg dev/vcpkg/vcpkg_installed
+```
+
+## Machine sizing
+
+`hostRequirements` asks for 4 CPUs, 16 GB of memory and 64 GB of storage.
Storage is
+the binding constraint: the image plus the Velox build tree does not fit the
32 GB
+disk of the smaller Codespaces machine types, so those are marked "Below dev
container
+requirements". Only Codespaces honours `hostRequirements`; other runtimes
ignore it,
+so size the Docker VM yourself.
+
+## Use another image
+
+Other pre-built images are published to
+[Docker Hub](https://hub.docker.com/r/apache/gluten/tags); their Dockerfiles
live in
+[`dev/docker/`](https://github.com/apache/gluten/tree/main/dev/docker) and are
+described in [Velox Backend CI](./velox-backend-CI.md#docker-build).
+`apache/gluten:centos-9-jdk17` is the same dynamic-link image with JDK 17 as
the
+default; `centos-8-*` variants build against an older glibc. To switch, edit
the
+`image` field in `.devcontainer/devcontainer.json`.
+
+To use these images outside a Dev Container, see
+[Build Gluten Velox backend in docker](./velox-backend-build-in-docker.md).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
