CI and Release Pipeline

GitHub Actions validates pull requests and pushes across Rust toolchains, operating systems, CPU targets, optional features, formatting, documentation, and selected generated artifacts. The main test matrix also exercises cross-compilation targets so failures are not limited to the host platform.

Releases are intentionally a separate path: a maintainer prepares and validates the repository by hand, pushes a version tag, and lets the release workflow create and build the GitHub release. A final checklist then covers release notes, crates.io publication, and Homebrew checksum updates.

Sources: .github/workflows/ci.yml:30-50

Core concepts

Pull-request CI

Pull-request CI is the ci workflow, which runs on pull_request; it also runs for pushes to master and on a scheduled cron.

Sources: .github/workflows/ci.yml:1-8

Test matrix

The test matrix is the test job’s collection of Rust toolchains, operating systems, and compilation targets. It includes pinned, stable, beta, and nightly Ubuntu builds, cross-compiled Linux targets, macOS, Windows MSVC, Windows GNU, and Windows ARM.

Sources: .github/workflows/ci.yml:30-50, .github/workflows/ci.yml:52-117

Release tag

A release tag is an x.y.z tag matching the release workflow’s tag pattern. Such a tag starts the release workflow and becomes the GitHub release version.

Sources: .github/workflows/release.yml:1-7, .github/workflows/release.yml:23-40

Release archive

A release archive is a target-specific directory named ripgrep-$version-${{ matrix.target }} containing the binary, licenses, documentation, and—when executable without emulation—generated shell completions and a man page.

Sources: .github/workflows/release.yml:210-233

What CI checks on every pull request

The test job checks out the repository, installs Ubuntu packages where needed, installs the matrix-selected Rust toolchain, and optionally configures cross for Ubuntu target builds. The workflow pins CROSS_VERSION to v0.2.5, and target builds set CARGO to cross, TARGET_FLAGS to the target option, and TARGET_DIR to a target-specific directory.

This workflow fans out from the pull request into the platform and quality checks below.

The diagram shows the workflow-level split; the test matrix additionally runs the zsh completion check only on non-Windows, non-cross builds.

Within test, CI builds the entire workspace normally and with the pcre2 feature, then runs tests with unstable-index. Native builds also test with pcre2; cross builds instead run tests without pcre2 because the integration tests use emulation and the PCRE2 variant would nearly double runtime.

The same job checks generated or CLI-facing behavior by testing zsh completions, printing the hostname detected by the CLI crate, and printing available short flags. Separate jobs compile for wasm32-wasip1, run cargo fmt --all --check, and build workspace documentation with RUSTDOCFLAGS: -D warnings.

Sources: .github/workflows/ci.yml:32-49, .github/workflows/ci.yml:118-146, .github/workflows/ci.yml:189-196, .github/workflows/ci.yml:154-187, .github/workflows/ci.yml:189-204, .github/workflows/ci.yml:207-246, ci/test-complete:39-84

How a release is cut and built

The manual release process starts by updating local master, reviewing dependency changes with cargo update and cargo outdated, updating the man-page date and CHANGELOG, and reviewing every crate under crates in the prescribed order. Crate changes may require new crate releases and dependent minimal-version updates.

The maintainer then edits Cargo.toml to the new ripgrep version, runs cargo update -p ripgrep, commits the changes, creates a signed tag, and verifies the package with cargo package. The changes are pushed without the tag; only after master CI succeeds is the version tag pushed.

This sequence captures the hand-off from manual preparation to the release workflow.

The create-release job obtains the version from the tag, checks that it appears in Cargo.toml, and creates a draft GitHub release with gh release create. The build-release job waits for it and builds the target matrix.

Release builds use pcre2, PCRE2_SYS_STATIC: 1, and the release-lto profile. The matrix covers Linux musl and GNU targets, macOS x86_64 and ARM64, Windows MSVC and GNU targets, Windows ARM64, and Windows 32-bit. Cross builds use target-specific strip tools and may use QEMU for emulation.

For each target, the workflow selects rg.exe on Windows or rg elsewhere, strips where required, creates the archive directory, and copies the binary plus README.md, COPYING, UNLICENSE, LICENSE-MIT, CHANGELOG.md, FAQ.md, and GUIDE.md. Platforms without emulation generate bash, fish, PowerShell, and zsh completions plus rg.1; emulated targets run those commands through the target container.

Sources: RELEASE-CHECKLIST.md:3-25, RELEASE-CHECKLIST.md:26-35, .github/workflows/release.yml:15-47, .github/workflows/release.yml:44-61, .github/workflows/release.yml:64-138, .github/workflows/release.yml:184-233, .github/workflows/release.yml:235-250

How checksums are published

After the tagged release is available, the checklist says to copy the relevant changelog section into the release notes, include the standard ripgrep description, run cargo publish, and execute ci/sha256-releases {VERSION}. Its output is appended to pkg/brew/ripgrep-bin.rb, where the maintainer updates the version and SHA-256 values and removes extraneous generated text.

ci/sha256-releases downloads release archives for i686 and x86_64 across apple-darwin and unknown-linux-musl, hashes each response with sha256sum, and also hashes the source .zip and .tar.gz downloads. This is why the Homebrew formula carries platform-specific release URLs and hashes for macOS and Linux binaries.

Sources: RELEASE-CHECKLIST.md:36-47, ci/sha256-releases:11-25, pkg/brew/ripgrep-bin.rb:1-12

How it connects

The CI build and feature checks complement Building and Installing, which explains source builds and feature flags; this page shows how those configurations are exercised automatically.

Generated completions and the man page connect to Packaging, Completions, and Docs Generation, while the zsh consistency check connects to CLI Entry and Flag Parsing because it compares completion options with rg --help.

The test coverage described here is the automation counterpart to Testing, Benchmarking, and Fuzzing; release preparation also depends on the contributor process described in Contributing and AI Policy.

Sources: .github/workflows/ci.yml:154-187, .github/workflows/release.yml:224-233, ci/test-complete:39-84

Key takeaways

• Pull requests run a broad Rust, platform, feature, formatting, documentation, Wasm, and completion matrix.
• Releases begin only from version-shaped tags after manual version, dependency, changelog, packaging, and CI checks.
• Release binaries are built per target with PCRE2 enabled and packaged with documentation and generated CLI artifacts.
• ci/sha256-releases hashes Linux, macOS, and source downloads for the Homebrew update.
• The checklist ends with release notes, cargo publish, formula changes, and a new TBD changelog section.