refactor!: remove experimental features from release builds

.github/workflows/ci-unit-tests-os.yml

@@ -73,7 +73,7 @@ jobs:
   ### Build and test Zebra on all OSes ###
   ########################################
   test:
-    name: Test ${{ matrix.rust }} on ${{ matrix.os }}${{ matrix.features }}
+    name: Test ${{ matrix.rust }} on ${{ matrix.os }}
     # The large timeout is to accommodate:
     # - macOS and Windows builds (typically 50-90 minutes), and
     timeout-minutes: 120
@@ -83,11 +83,9 @@ jobs:
       matrix:
         os: [ubuntu-latest, macos-latest, windows-latest]
         rust: [stable, beta]
-        # TODO: When vars.EXPERIMENTAL_FEATURES has features in it, add it here.
-        #       Or work out a way to trim the space from the variable: GitHub doesn't allow empty variables.
-        #       Or use `default` for the empty feature set and EXPERIMENTAL_FEATURES, and update the branch protection rules.
-        #features: ${{ fromJSON(format('["", "{0}"]', vars.EXPERIMENTAL_FEATURES)) }}
-        features: [""]
+        # We only test with default features in this workflow
+        # Other feature combinations are tested in specific workflows
+        features: ["default-release-binaries"]
         exclude:
         # We're excluding macOS beta for the following reasons:
         # - the concurrent macOS runner limit is much lower than the Linux limit
@@ -121,8 +119,7 @@ jobs:
         #with:
         #  workspaces: ". -> C:\\zebra-target"
         with:
-          # Split the experimental features cache from the regular cache, to avoid linker errors.
-          # (These might be "disk full" errors, or they might be dependency resolution issues.)
+          # Split the cache by feature set to avoid linker errors
           key: ${{ matrix.features }}
 
       - name: Change target output directory on Windows

.github/workflows/release-binaries.yml

@@ -15,30 +15,9 @@ on:
       - released
 
 jobs:
-  # Each time this workflow is executed, a build will be triggered to create a new image
-  # with the corresponding tags using information from git
-
-  # The image will be named `zebra:<semver>-experimental`
-  build-experimental:
-    name: Build Experimental Features Release Docker
-    uses: ./.github/workflows/sub-build-docker-image.yml
-    with:
-      dockerfile_path: ./docker/Dockerfile
-      dockerfile_target: runtime
-      image_name: zebra
-      tag_suffix: -experimental
-      features: ${{ format('{0} {1}', vars.RUST_PROD_FEATURES, vars.RUST_EXPERIMENTAL_FEATURES) }}
-      rust_log: ${{ vars.RUST_LOG }}
-    # This step needs access to Docker Hub secrets to run successfully
-    secrets: inherit
-
   # The image will be named `zebra:<semver>`
-  # It should be built last, so tags with the same name point to the production build, not the experimental build.
   build:
     name: Build Release Docker
-    # Run this build last, regardless of whether experimental worked
-    needs: build-experimental
-    if: always()
     uses: ./.github/workflows/sub-build-docker-image.yml
     with:
       dockerfile_path: ./docker/Dockerfile
@@ -53,7 +32,7 @@ jobs:
   failure-issue:
     name: Open or update issues for release binaries failures
     # When a new job is added to this workflow, add it to this list.
-    needs: [ build, build-experimental ]
+    needs: [ build ]
     # Open tickets for any failed build in this workflow.
     if: failure() || cancelled()
     runs-on: ubuntu-latest

CHANGELOG.md

@@ -5,6 +5,13 @@ All notable changes to Zebra are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org).
 
+## [Unreleased]
+
+### Breaking Changes
+
+- Remove experimental features from release builds and workflows
+
+
 ## [Zebra 2.2.0](https://github.com/ZcashFoundation/zebra/releases/tag/v2.2.0) - 2025-02-03
 
 In this release, Zebra introduced an additional consensus check on the branch ID of Nu6 transactions

book/src/user/docker.md

@@ -17,8 +17,6 @@ If you want to preserve Zebra's state, you can create a Docker volume:
 docker volume create zebrad-cache
 ```
 
-And mount it before you start the container:
-
 ```shell
 docker run \
   --mount source=zebrad-cache,target=/home/zebra/.cache/zebra \
@@ -54,10 +52,34 @@ docker build \
   .
 ```
 
+### Alternatives
+
+See [Building Zebra](https://github.com/ZcashFoundation/zebra#building-zebra) for more information.
+
+## Advanced usage
+
+You're able to specify various parameters when building or launching the Docker image, which are meant to be used by developers and CI pipelines. For example, specifying the Network where Zebra will run (Mainnet, Testnet, etc), or enabling features like metrics with Prometheus.
+
+### Building with Custom Features
+
+Zebra supports various features that can be enabled during build time using the `FEATURES` build argument:
+
+For example, if we'd like to enable metrics on the image, we'd build it using the following `build-arg`:
+
+> [!IMPORTANT]
+> To fully use and display the metrics, you'll need to run a Prometheus and Grafana server, and configure it to scrape and visualize the metrics endpoint. This is explained in more detailed in the [Metrics](https://zebra.zfnd.org/user/metrics.html#zebra-metrics) section of the User Guide.
+
+```shell
+# Build with specific features
+docker build -f ./docker/Dockerfile --target runtime \
+    --build-arg FEATURES="default-release-binaries prometheus" \
+    --tag zebra:metrics .
+```
+
 All available Cargo features are listed at
 <https://docs.rs/zebrad/latest/zebrad/index.html#zebra-feature-flags>.
 
-## Configuring Zebra
+## Configuring Zebra with Docker Compose
 
 To configure Zebra, edit the `docker/default-zebra-config.toml` config file and
 uncomment the `configs` mapping in `docker/docker-compose.yml` so your config