The provider is published in lockstep with LiteLLM: every dev, rc and stable release mirrors terraform/provider/ from the release commit and tags it with the LiteLLM version, alongside the aws/google modules. The 0.x line ends at 0.4.0, and the CHANGELOG headings no longer drive a release. RELEASING.md describes the new flow and how to recover a version whose goreleaser run failed; README gains a Versioning section with the re-pin note for anyone on `~> 0.4`; CHANGELOG records the change under Unreleased. goreleaser gets `prerelease: auto` so a v1.99.0-dev.1 / -rc.1 tag in the mirror is marked as a pre-release instead of becoming the repo's latest release. The registry ingests it either way.
7.7 KiB
Release Process
This document describes the release process for the LiteLLM Terraform Provider.
Overview
The provider is released in lockstep with LiteLLM: every LiteLLM release (dev, rc and stable) publishes the provider at the LiteLLM version, built from the same commit as the proxy. There is no separate provider release to cut.
The flow, end to end:
BerriAI/project-releaser's release pipeline resolves the commit to release (mainHEAD for dev;mainHEAD or an operator-supplied SHA for rc/stable) and passes the release approval gate- Its componentized terraform job rsyncs
terraform/provider/from that commit intoBerriAI/terraform-provider-litellm, commits, and pushes the tagv<litellm version>(for examplev1.99.0,v1.99.0-rc.1,v1.99.0-dev.1), alongside theterraform-aws-litellm/terraform-google-litellmmodule mirrors which get the same tag - The tag push triggers the mirror's own
Releaseworkflow (goreleaser): multi-platform build, GPG-signed checksums, GitHub release. It runs unattended; project-releaser does not wait for it - The public Terraform Registry ingests the GitHub release as provider version
<litellm version>
terraform/provider/ only exists from LiteLLM ~1.95, so a stable patch cut from an older line skips the provider and publishes only the modules.
Prerequisites
GPG Key Setup (One-Time Setup for Repository Maintainers)
The Terraform Registry requires all providers to be signed with a GPG key. This must be configured before the first release.
1. Generate a GPG Key
If you don't already have a GPG key for provider signing:
gpg --full-generate-key
Configuration:
- Key type: RSA and RSA (default)
- Key size: 4096 bits
- Expiration: No expiration (or set a long expiration period)
- Email: Use an email associated with your GitHub account
- Set a strong passphrase (or leave empty for CI/CD use)
2. Export the GPG Key
# List your keys to get the key ID
gpg --list-secret-keys --keyid-format=long
# Example output:
# sec rsa4096/ABCD1234EFGH5678 2024-01-01 [SC]
# 1234567890ABCDEF1234567890ABCDEF12345678
# uid [ultimate] Your Name <your.email@example.com>
#
# The key ID is: ABCD1234EFGH5678
# The fingerprint is: 1234567890ABCDEF1234567890ABCDEF12345678
# Export the private key (ASCII-armored format)
gpg --armor --export-secret-keys ABCD1234EFGH5678
# Export the public key
gpg --armor --export ABCD1234EFGH5678
3. Configure GitHub Repository Secrets
Add the following secrets to the repository at: Settings → Secrets and variables → Actions → New repository secret
| Secret Name | Description | Value |
|---|---|---|
GPG_PRIVATE_KEY |
The GPG private key for signing releases | Full output from gpg --armor --export-secret-keys (including -----BEGIN PGP PRIVATE KEY BLOCK----- and -----END PGP PRIVATE KEY BLOCK-----) |
PASSPHRASE |
The passphrase for the GPG key | Your GPG key passphrase (leave empty if no passphrase was set) |
4. Register Public Key with Terraform Registry
Before publishing to the Terraform Registry:
- Go to https://registry.terraform.io/settings/gpg-keys
- Click "Add a key"
- Paste your public GPG key (output from
gpg --armor --export) - Submit
Note: The public key fingerprint must match the key used to sign the provider releases.
What a change needs
- Land it in
BerriAI/litellm. Open a PR againstlitellm_internal_stagingwith the source change and aCHANGELOG.mdentry under[Unreleased]. CI runsgofmt,go vet, build, tests and the endpoint-drift audit. A change that breaks existing configurations or state must say so in the changelog: the version number cannot signal it any more - Wait for the next LiteLLM release. The nightly dev release carries it within a day; it reaches a stable version on the next stable cut
- Verify (optional): the version appears at https://registry.terraform.io/providers/BerriAI/litellm and https://github.com/BerriAI/terraform-provider-litellm/releases. If the tag is on the mirror but there is no release, the goreleaser run failed: https://github.com/BerriAI/terraform-provider-litellm/actions
Locally, before opening the PR:
make test
make build
Out-of-band publish or recovery
Dispatch Build and Publish Componentized Images + Chart in BerriAI/project-releaser by hand with only publish_terraform enabled and the git_ref / tag of the release to (re)publish. The run waits on project-releaser's release approval, then mirrors and tags exactly as the pipeline does.
The mirror is push-only: do not commit or tag BerriAI/terraform-provider-litellm directly. The publish refuses to overwrite an existing tag; a version that failed in goreleaser is recovered by re-running the mirror's Release workflow for that tag, not by re-tagging.
The mirror's .github/ directory (the Release workflow) is the one thing the rsync preserves, so a change to the goreleaser workflow is a direct PR on the mirror; a change to .goreleaser.yml itself lands here like any other source change.
Troubleshooting
Release Workflow Fails with GPG Error
Error: Input required and not supplied: gpg_private_key
Solution:
- Verify that
GPG_PRIVATE_KEYandPASSPHRASEsecrets are configured in the repository - Ensure the secrets are not expired
- Check that the secret names match exactly (case-sensitive)
GoReleaser Signing Fails
Error: gpg: signing failed: No secret key
Solution:
- Verify the
GPG_PRIVATE_KEYsecret contains the complete private key block - Ensure the passphrase is correct
- Check that the key hasn't expired:
gpg --list-keys
Build Fails
Error: Build errors during compilation
Solution:
- Run
make testandmake buildlocally first - Ensure
go.modandgo.sumare up to date - Check that all dependencies are available
Tag Already Exists
Error: The publish job refuses to push because the tag already exists on the mirror
Solution: Tags are immutable by design and the version is the LiteLLM version, so this means the provider was already mirrored for this release. If the registry is missing the version, re-run the mirror's Release workflow for the existing tag rather than re-tagging
Version Numbering
The provider version is the LiteLLM version, verbatim: X.Y.Z for a stable release, X.Y.Z-rc.N for a release candidate and X.Y.Z-dev.N for a nightly. It says which proxy the provider shipped with and was audited against; it does not follow SemVer's break-signalling, so breaking changes are announced in CHANGELOG.md and the registry docs instead.
Versions 0.1.0 to 0.4.0 predate this and remain in the registry on their own line. A ~> 0.4 constraint never receives another release.
Security Considerations
- Never commit private keys: The GPG private key should only be stored as a GitHub secret
- Protect repository secrets: Limit who has access to manage repository secrets
- Use a dedicated key: Consider using a separate GPG key specifically for provider signing
- Key rotation: If the GPG key is compromised, generate a new key, update secrets, and register the new public key with the Terraform Registry
- Passphrase: Use a strong passphrase for the GPG key, or use a passphrase-less key specifically for CI/CD