---
title: Cargo features
description: Every rtb-forge Cargo feature, whether it is on by default, and what disabling it removes from the public API.
tags: [reference, cargo, features]
---
# Cargo features
`rtb-forge` is feature-gated so a tool that only talks to one forge does not
compile the other five backends, and a tool that never touches a working tree
does not compile `gix`.
## What is enabled by default?
```toml
[dependencies]
rtb-forge = "0.7"
```
That pulls in the default set:
```toml
default = ["github", "gitlab", "gitea", "codeberg", "direct", "bitbucket", "git"]
```
Every built-in release backend, plus the git-operations slice.
## What does each feature do?
| `github` | on | `_http` | `rtb_forge::github`, `source_type: github` |
| `gitlab` | on | `_http` | `rtb_forge::gitlab`, `source_type: gitlab` |
| `gitea` | on | `_http` | `rtb_forge::gitea`, `source_type: gitea` |
| `codeberg` | on | `gitea` | `rtb_forge::codeberg`, `source_type: codeberg` |
| `bitbucket` | on | `_http` | `rtb_forge::bitbucket`, `source_type: bitbucket` |
| `direct` | on | `_http` | `rtb_forge::direct`, `source_type: direct` |
| `git` | on | `gix`, `rtb-credentials`, `futures-core` | the whole `rtb_forge::git` module, including `Repo` |
| `integration` | off | nothing at runtime | compiles the testcontainers-backed Gitea test suite |
| `_http` | off (internal) | `reqwest`, `serde_json`, `bytes`, `futures-util`, `tokio-util` | nothing; shared plumbing only |
`config` and `release` are **not** feature-gated. `ReleaseSourceConfig`,
`ReleaseProvider`, `Release`, `ReleaseAsset`, `ProviderError`, `lookup` and
`registered_types` compile with every feature turned off.
## Why does enabling `codeberg` also enable `gitea`?
The Codeberg backend has no HTTP code of its own. Its factory builds
`GiteaParams` with `host` pinned to `codeberg.org` and hands them to
`gitea::build_provider`. Cargo expresses that as `codeberg = ["gitea"]`, so a
build with `features = ["codeberg"], default-features = false` still registers
**both** `codeberg` and `gitea` in `RELEASE_PROVIDERS`. There is no way to get
the Codeberg backend without the Gitea one.
## How do I compile only one backend?
Turn the defaults off and name what you want:
```toml
[dependencies]
rtb-forge = { version = "0.7", default-features = false, features = ["github"] }
```
That build registers exactly one `source_type`. `rtb_forge::lookup("gitlab")`
returns `None`, and `registered_types()` returns `["github"]`. Handing a
`ReleaseSourceConfig::Gitlab` to the GitHub factory is a configuration error,
not a panic. See
[`ProviderError::InvalidConfig`](04-provider-errors.md#invalidconfig).
## How do I compile without any git support?
```toml
[dependencies]
rtb-forge = { version = "0.7", default-features = false, features = ["github"] }
```
Omitting `git` removes the `rtb_forge::git` module entirely (`Repo`,
`RepoError`, `CloneOptions`, `CommitWalk`, all of it) and drops `gix`,
`rtb-credentials` and `futures-core` from the dependency graph. Code that
names any of those types will not compile.
## What is the `integration` feature for?
It gates the testcontainers-backed Gitea suite behind
`#[cfg(feature = "integration")]`. It adds nothing to the library at runtime.
Enabling it means `cargo test` will try to start a `gitea/gitea:1.24`
container, so it needs a working Docker daemon:
```bash
just test-integration # cargo nextest run --features integration
```
Because `--all-features` turns `integration` on, CI lanes that run
`--all-features` without Docker exclude the integration binaries with a nextest
filter (`-E '!binary(/_integration$/)'`). The containers are serialised to one
at a time by `.config/nextest.toml`; running them in parallel exhausts
testcontainers' 60-second startup timeout on shared runners.
## What is the `_http` feature for?
Nothing you should name. It is the shared HTTP dependency set that every REST
backend needs, declared as its own feature so the deps appear once rather than
six times. It is enabled transitively; naming it directly gets you the
dependencies without any backend registered.
## Is there a `git2-fallback` feature?
No. Earlier design notes reserved a `git2-fallback` opt-in for operations
`gix` could not perform, push mainly. It was never declared in `Cargo.toml`,
because every write path in this crate shells out to the `git` binary instead
of using libgit2. `cargo build --features git2-fallback` fails with
`error: the package 'rtb-forge' does not contain this feature: git2-fallback`.
Push failures arrive as `RepoError::PushFailed` on any build with `git`
enabled.
`libgit2` is not a dependency of this crate under any feature combination.