Skip to main content

Overview

HelixCommit offers flexible configuration through configuration files, command-line flags, and environment variables. You can customize how commits are processed, what gets included in release notes, and how output is formatted.

Configuration methods

Configuration files

Store project defaults in .helixcommit.toml or .helixcommit.yaml. Best for team-wide settings.

Command-line flags

Pass options directly when running commands. Best for one-off customizations and testing.

Environment variables

Set variables in your shell or CI/CD environment. Ideal for credentials and secrets.

Configuration precedence

When the same option is set in multiple places, HelixCommit uses this precedence (highest to lowest):
  1. Command-line flags - Always take priority
  2. Configuration file - Project defaults from .helixcommit.toml or .helixcommit.yaml
  3. Built-in defaults - Fallback values

Configuration files

HelixCommit looks for configuration files in your repository root in this order:
  1. .helixcommit.toml (TOML format)
  2. .helixcommit.yaml (YAML format)
The first file found is used. Configuration files are optional - HelixCommit works without them.

Custom config file location

Use the --config flag to specify a custom config file location instead of the default discovery:
The --config flag is available on both generate and generate-commit commands.
Maintain different configurations for different release types:
Store team-wide settings in a central location:
Use different configs per CI environment:
Template paths in custom config files are resolved relative to the config file’s location, not the repository root.
Create a .helixcommit.toml file in your repository root:
Never store API keys or tokens in configuration files. Use environment variables for sensitive credentials like OPENAI_API_KEY, GITHUB_TOKEN, etc.

Environment variable expansion

Configuration files support environment variable expansion using the ${VAR} syntax. This allows you to reference environment variables directly in your config files, making configurations more portable across different environments.
Use ${VAR_NAME} to reference an environment variable:
Set the variables before running:
Use environment variables to switch between development and production settings:
Then configure per environment:
Reference template directories via environment variables:
Configure expert roles per team member or CI environment:
If an environment variable is not set and no default is provided, the reference (e.g., ${UNDEFINED_VAR}) is kept as-is in the config value.
Environment variable expansion is for non-sensitive configuration values like model names, domains, and paths. Never use this feature for API keys or tokens - those should always be set as environment variables directly and accessed by the application.

Configuration reference

Example configurations

Then set your API key:

Core configuration areas

Commit range selection

Control which commits are included in your release notes.
Use semantic version tags to define ranges:
The --unreleased flag automatically uses the latest tag as the starting point.

Output formatting

Customize how release notes are formatted and where they’re saved.
string
default:"markdown"
Choose the output format that fits your publishing workflow.Markdown - Perfect for GitHub releases and documentation sites
HTML - Ready for embedding in websites
Text - Plain text for email notifications or chat
JSON - Machine-readable for programmatic use
string
Control where output is written.Standard output (default)
File output
Parent directories are created automatically if they don’t exist.

Filtering commits

Fine-tune which commits appear in your release notes.
Merge commits often duplicate information. Excluding them typically produces cleaner release notes.
Useful for testing or when you only need recent changes.
Scopes are extracted from Conventional Commits format: feat(api): message

GitHub integration

Configure how GitReleaseGen interacts with GitHub’s API.

Authentication

1

Create a GitHub token

Visit github.com/settings/tokens and create a personal access token.For public repositories: No special permissions neededFor private repositories: Select the repo scope
2

Set the token

Never commit tokens to version control. Use environment variables or CI/CD secrets.

Rate limiting and retries

GitReleaseGen handles GitHub API rate limits automatically with exponential backoff.
integer
default:"3"
Maximum number of retry attempts for failed requests.
float
default:"0.5"
Initial delay between retries in seconds.
float
default:"8"
Maximum delay between retries in seconds.

Caching

Reduce API calls and improve performance with caching.
boolean
default:"false"
Enable persistent caching of GitHub API responses.
Valid values: 1, true, yes, on
path
default:".gitreleasegen-cache/github"
Directory where cache files are stored.
integer
default:"10"
How long cache entries remain valid in minutes.
Enable caching in CI/CD environments to speed up repeated runs and reduce API usage.

Skip GitHub integration

Work offline or skip PR lookups:
Using --no-prs means no GitHub API calls are made. Perfect for offline work or when PR metadata isn’t needed.

GitLab integration

HelixCommit automatically detects GitLab repositories (including self-hosted instances) and enriches release notes with merge request data.

Authentication

Required permissions: read_api and read_repository for private projects.
For more details, see the GitLab integration guide.

Bitbucket integration

HelixCommit automatically detects Bitbucket Cloud repositories and enriches release notes with pull request data.

Authentication

Required permissions: Repositories: Read, Pull requests: Read
For more details, see the Bitbucket integration guide.

AI configuration

Configure AI-powered summarization features.

Provider selection

Recommended models:
  • gpt-4o-mini - Fast and cost-effective (recommended)
  • gpt-4o - Most capable
  • gpt-3.5-turbo - Budget option
Get your API key at platform.openai.com/api-keys

Summary caching

AI summaries are cached to minimize token usage and costs.
Delete the cache file to regenerate all summaries with updated prompts or settings.

Prompt engineering

Customize AI behavior with advanced options:
string
Set the domain context for better AI summaries.
Examples: "conservation", "healthcare", "finance", "e-commerce"
string[]
Define expert roles for multi-perspective analysis.
Default roles: Product Manager, Tech Lead, QA Engineer
string
default:"simple"
Choose the retrieval backend for context.

Example configurations

Generate release notes with no external dependencies:
Perfect for local development or air-gapped environments.
Fast generation for automated pipelines:
Balanced configuration for team use:

Custom templates

GitReleaseGen uses formatters to render output. You can customize the look and feel by modifying templates.

Template locations

Templates are located in the GitReleaseGen package:

Creating custom formatters

1

Copy an existing formatter

2

Modify the template

Edit the rendering logic to match your needs. Formatters use Jinja2 templates for rendering.
3

Use programmatically

For more details on programmatic usage, see the Python API reference.

Environment file

Create a .env file to store configuration:
.env
Load it before running commands:
Add .env to your .gitignore to avoid committing secrets.

Next steps

CLI reference

Complete list of all CLI options

AI features

Learn about AI-powered summarization

Examples

See configuration in action

GitHub integration

Deep dive into GitHub API features