Skip to content

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?

[dependencies]
rtb-forge = "0.7"

That pulls in the default set:

default = ["github", "gitlab", "gitea", "codeberg", "direct", "bitbucket", "git"]

Every built-in release backend, plus the git-operations slice.

What does each feature do?

Feature Default Enables Public API it adds
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:

[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.

How do I compile without any git support?

[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:

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.

Two leftovers from that plan are still visible and are misleading:

  • RepoError::PushUnsupported exists in the enum but is never constructed. Its message and help text tell you to enable git2-fallback. You will never receive this variant.
  • RepoError::PushFailed's API docs say it is "only reachable when the git2-fallback Cargo feature is enabled". It is in fact the normal failure variant for Repo::push and is reachable on any build with git enabled.

libgit2 is not a dependency of this crate under any feature combination.