rlsy (pronounced "release-ee") is a powerful CLI tool that automates the entire release process for your projects. It generates changelogs from git commits, manages semantic versioning, updates version files, and creates GitLab releases - all with intelligent defaults and a user-friendly workflow.

Features

- Automated Changelog Generation - Generate Keep a Changelog formatted changelogs from git commits with smart categorization
- Interactive Version Management - Semantic versioning with guided prompts and cursor key navigation for patch, minor, major, or custom versions
- Multi-File Version Updates - Automatically update version numbers across multiple files (package.json, Chart.yaml, Dockerfile, source code, documentation, and more)
- NPM Publishing - Automated package publishing to npm with support for npm, yarn, and pnpm (auto-detected from lock files)
- Helm Chart Support - Built-in support for Helm charts with independent versioning for charts and applications
- Dry-Run Mode - Preview all changes before execution with comprehensive diffs and operation summaries
- GitLab & GitHub Integration - Seamlessly create releases on GitLab (via glab) or GitHub (via gh) with curated changelog as release notes
- Stable Branch Protection - Prevent accidental breaking changes on stable branches
- Zero Configuration - Works out of the box with sensible defaults, configure only what you need
- Git-First Approach - Leverages your existing git history and commit conventions

Installation

$3

rlsy requires the following tools to be installed:

- Node.js >= 18.0.0
- git (for version control operations)
- glab (GitLab CLI) - Installation instructions

$3

``bash


Install globally via npm

npm install -g rlsy

Or use directly with npx

npx rlsy
`

$3

rlsy uses your preferred text editor to curate changelogs. Set the $EDITOR environment variable:

`bash


Add to your shell profile (~/.bashrc, ~/.zshrc, etc.)


export EDITOR=vim # or nano, emacs, code, etc.
`

$3

If you haven't already, authenticate glab with your GitLab instance:

`bash
glab auth login
`

Quick Start

$3

First time using rlsy? Run the interactive setup wizard:

`bash


Interactive configuration setup

rlsy init

Or use auto-detected defaults

rlsy init --yes
`

This creates a .rlsyrc.yaml file with smart defaults based on your project structure.

$3

Here's how to create your first release with rlsy:

`bash


1. Make sure your working directory is clean

git status

2. Run rlsy

rlsy

3. Follow the interactive prompts:

- Select version type (patch/minor/major)

- Review and edit the generated changelog in your editor

- Confirm the release

`

That's it! rlsy will:

- Update all version files
- Create an annotated git tag
- Push changes to remote
- Create a GitLab release

$3

`bash


Preview what rlsy will do without making any changes


rlsy --dry-run
`

Usage

$3

`bash


Initialize configuration (first time setup)

rlsy init

Initialize with auto-detected defaults

rlsy init --yes

Create a release (interactive)

rlsy
rlsy release

Preview changes without executing

rlsy --dry-run

Use custom configuration file

rlsy --config .rlsy/production.yaml

Enable verbose logging for debugging

rlsy --verbose

Combine options

rlsy --dry-run --verbose
`

$3

| Option | Alias | Description |
|--------|-------|-------------|
| --dry-run | -d | Preview all changes without executing them |
| --verbose | -v | Enable verbose logging for debugging |
| --config | -c | Specify custom config file path |
| --yes | -y | Use defaults without prompts (init command) |
| --force | -f | Force overwrite existing config (init command) |
| --help | -h | Show help information |
| --version | | Show rlsy version |

$3

The rlsy init command helps you set up rlsy configuration interactively:

`bash


Interactive setup with prompts

rlsy init

Auto-accept detected defaults

rlsy init --yes

Overwrite existing config without confirmation

rlsy init --force

Preview configuration without writing

rlsy init --dry-run
`

What it does:

- Detects your project structure (git repository, Helm charts, package.json)
- Identifies version files automatically
- Prompts for configuration preferences
- Creates .rlsyrc.yaml with smart defaults
- Validates configuration before writing

Auto-detected settings:

- Git repository and remote URL
- Helm charts in helm/ directory
- package.json version field
- Current branch and version
- Potential version files (README.md, Dockerfile, etc.)

The init command is optional - rlsy works without configuration using intelligent defaults. Use it when you want to customize behavior or version file updates.

Configuration

$3

rlsy looks for configuration in the following locations (in order):

1. .rlsyrc.yaml (repository root)
2. .rlsy/config.yaml

Configuration is optional - rlsy works with zero configuration using intelligent defaults.

$3

`yaml


Project configuration

project:
enabled: true
tagFormat: v{version}

Changelog configuration

changelog:
file: CHANGELOG.md

Git configuration

git:
pushTags: true
pushCommits: true

GitLab configuration

gitlab:
createRelease: true
releaseBranch: main
`

$3

See .rlsyrc.example.yaml for a complete configuration example with all available options.

$3

#### Project Configuration

`yaml
project:
enabled: true
tagFormat: v{version}
versionFiles:
- file: package.json
jsonPath: version
- file: VERSION
type: plain
- file: README.md
pattern: 'Version\s+v([0-9.]+)'
replacement: Version v{version}
`

- enabled - Enable/disable project versioning (default: true)
- tagFormat - Git tag format template (default: v{version})
- versionFiles - Array of files to update with the project version

#### Helm Configuration

`yaml
helm:
enabled: true
autoDetect: true
directory: helm
charts:
- name: my-app
path: helm/my-app
tagFormat: "{name}-{version}"
versionFiles:
- file: helm/my-app/values.yaml
yamlPath: image.tag
`

- enabled - Enable/disable Helm chart support (default: true)
- autoDetect - Automatically detect Helm charts (default: true)
- directory - Base directory to scan for charts (default: helm)
- charts - Array of explicit chart configurations

#### Changelog Configuration

`yaml
changelog:
file: CHANGELOG.md
includeMergeCommits: false
smartMergeDetection: true
commitTypes:
add: Added
fix: Fixed
change: Changed
remove: Removed
security: Security
`

- file - Changelog file path (default: CHANGELOG.md)
- includeMergeCommits - Include merge commits in changelog (default: false)
- smartMergeDetection - Filter out generic merge commits (default: true)
- commitTypes - Map commit prefixes to changelog sections (commits that don't match are filtered out)

#### Branch Configuration

`yaml
branches:
stable:
pattern: stable-*
allowNonPatch: false
confirmOverride: true
`

- stable.pattern - Glob pattern for stable branches
- stable.allowNonPatch - Allow minor/major versions on stable branches
- stable.confirmOverride - Prompt before allowing non-patch versions

#### Git Configuration

`yaml
git:
pushTags: true
pushCommits: true
`

- pushTags - Automatically push tags after creation
- pushCommits - Automatically push commits after creation

Note: A clean working directory is always required (not configurable).

#### GitLab Configuration

`yaml
gitlab:
createRelease: true
releaseBranch: main
`

- createRelease - Create GitLab release via glab (default: true)
- releaseBranch - Branch to create release from (default: main)

Workflow

rlsy follows a structured 5-phase workflow:

$3

- Verify git repository exists and has remote configured
- Check working directory is clean (no uncommitted changes)
- Verify $EDITOR is set (normal mode only)

$3

- Load configuration file (if exists)
- Auto-detect or configure Helm charts
- Determine last release version from git tags
- Interactive tag selection if needed (multiple tags, ambiguous versions)

$3

- Prompt for new version with options:
- Patch (e.g., 1.2.3 → 1.2.4) - Bug fixes
- Minor (e.g., 1.2.3 → 1.3.0) - New features, backward compatible
- Major (e.g., 1.2.3 → 2.0.0) - Breaking changes
- Pre-release (e.g., 1.2.3 → 1.3.0-alpha.1) - Alpha, beta, rc versions
- Custom - Enter any valid semver version
- Validate semver format
- Apply stable branch restrictions if applicable

$3

- Generate changelog draft from git commits since last version
- Categorize commits into Keep a Changelog sections:
- Added - New features
- Changed - Changes to existing functionality
- Deprecated - Soon-to-be removed features
- Removed - Removed features
- Fixed - Bug fixes
- Security - Security fixes
- Open changelog in $EDITOR for manual curation
- User edits, reorganizes, and enhances the changelog
- Save and close editor to continue

In dry-run mode: Display generated changelog to stdout (no editor)

$3

In normal mode:

1. Update version files (package.json, Chart.yaml, etc.)
2. Update CHANGELOG.md with curated changelog
3. Create git commit with message: chore: release v{version}
4. Create annotated git tags with release notes
5. Publish to npm (if enabled and package.json exists, with confirmation)
6. Push commits and tags to remote (with confirmation)
7. Create GitLab/GitHub release with curated changelog

In dry-run mode:

1. Display file changes as unified diffs
2. Show git operations (commit message, tags)
3. Show npm publishing preview (package name, version, files)
4. Display remote operations (push commands)
5. Show GitLab/GitHub release details
6. No actual changes made

Version File Updates

rlsy can automatically update version numbers in multiple files across your project.

$3

Without any configuration, rlsy automatically detects and updates:

- package.json - Updates the version field
- Chart.yaml (Helm) - Updates version and appVersion fields

$3

rlsy supports four strategies for updating version files:

#### 1. JSON Path Updates

Update specific fields in JSON files:

`yaml
- file: package.json
jsonPath: version
`

#### 2. YAML Path Updates

Update specific fields in YAML files:

`yaml
- file: config.yaml
yamlPath: app.version
`

Supports nested paths with dot notation (e.g., metadata.version).

#### 3. Pattern-Based Updates (Regex)

Use regex to find and replace version strings in any file:

`yaml
- file: README.md
pattern: 'Version\s+v([0-9.]+)'
replacement: Version v{version}
`

- pattern - Regex with capture group 1 for the version
- replacement - Template with {version} placeholder

#### 4. Plain Text Updates

Replace entire file content with version string:

`yaml
- file: VERSION
type: plain
`

$3

#### Update version in README badge

`yaml
- file: README.md
pattern: 'badge\/version-([0-9.]+)-'
replacement: badge/version-{version}-
`

#### Update Dockerfile version label

`yaml
- file: Dockerfile
pattern: 'LABEL version="([^"]+)"'
replacement: 'LABEL version="{version}"'
`

#### Update version constant in source code

`yaml
- file: src/version.js
pattern: 'export const VERSION = "''["'']'
replacement: "export const VERSION = '{version}'"
`

#### Update Helm values.yaml image tag

`yaml
- file: helm/my-app/values.yaml
yamlPath: image.tag
`

#### Update multiple version references in same file

Configure multiple entries for the same file:

`yaml
- file: README.md
pattern: 'Version:\s*v([0-9.]+)'
replacement: 'Version: v{version}'
- file: README.md
pattern: 'download\/v([0-9.]+)\/'
replacement: download/v{version}/
`

Changelog Generation

rlsy generates changelogs following the Keep a Changelog format.

$3

rlsy recognizes multiple commit message formats:

#### Keep a Changelog Style (Recommended)

`
Add: user authentication with OAuth2
Added rate limiting middleware
Fix: memory leak in connection pool
Fixed race condition in cache
Change: database pooling strategy
Remove deprecated API
`

Note: Commits with colons (Add:, Fix:) have the prefix removed in the changelog. Commits without colons keep the full message.

$3

Commits are automatically categorized into changelog sections:

| Commit Prefix | Changelog Section | Examples |
|--------------|------------------|----------|
| add, added | Added | New features |
| fix, fixed | Fixed | Bug fixes |
| change, changed | Changed | Modifications |
| remove, removed, delete, deleted | Removed | Removed features |
| deprecate, deprecated | Deprecated | Deprecations |
| security, sec | Security | Security fixes |
| breaking, break | Changed | Breaking changes |
| Everything else | Filtered out | Not in changelog |

Features:

- Case-insensitive matching
- Works with or without colons (Fix: or Fix)
- Handles present and past tense (Add or Added)
- Automatically capitalizes changelog entries
- Unrecognized commits are filtered out (e.g., feat:, chore:, Update, refactor:)

$3

By default, merge commits are excluded from changelogs. Enable them with:

`yaml
changelog:
includeMergeCommits: true
smartMergeDetection: true
`

With smartMergeDetection: true, generic merge commits are filtered out:

- ✗ Skip: Merge branch 'main'
- ✓ Include: Merge pull request #123: Add user authentication

$3

Add your own commit type mappings:

`yaml
changelog:
commitTypes:
docs: Documentation
style: Changed
test: Testing
build: Changed
`

Helm Chart Support

rlsy has first-class support for Helm charts with independent versioning.

$3

rlsy automatically detects Helm charts by scanning for:

- helm/ directory (configurable)
- Chart.yaml files

$3

Helm charts and projects can have independent versions:

- Chart version - Helm chart release version (Chart.yaml → version)
- App version - Application version being deployed (Chart.yaml → appVersion)

During release, you'll be prompted for:

1. Helm chart version (e.g., 2.1.0)
2. Project version (e.g., 1.5.3)

The Chart.yaml is updated with both:

`yaml
apiVersion: v2
name: my-app
version: 2.1.0 # Chart version (user-selected)
appVersion: "1.5.3" # Project version (tracks app)
`

$3

rlsy supports multiple Helm charts in a single repository:

`yaml
helm:
charts:
- name: frontend
path: helm/frontend
tagFormat: "{name}-{version}"
- name: backend
path: helm/backend
tagFormat: "{name}-{version}"
`

Each chart is versioned independently with its own git tag.

$3

For projects that only contain Helm charts (no separate application):

`yaml
project:
enabled: false

helm:
enabled: true
`

In this mode, Chart.yaml appVersion will match the chart version.

$3

Update additional files with the Helm chart version:

`yaml
helm:
charts:
- name: my-app
path: helm/my-app
versionFiles:
- file: helm/my-app/README.md
pattern: 'Chart Version:\s*([^]+)'
replacement: 'Chart Version: {version}'
- file: helm/my-app/values.yaml
yamlPath: image.tag
``

These files are updated with the Helm chart version (not project version).

NPM Publishing

rlsy can automatically publish your package to npm as part of the release workflow.

$3

rlsy automatically detects npm packages by looking for package.json in your repository root. When detected, it will prompt you whether to publish during the release.

$3

rlsy supports npm, yarn, and pnpm with automatic detection from lock files:

- pnpm-lock.yaml → uses pnpm
- yarn.lock → uses yarn (handles both 1.x and 2+ versions)
- package-lock.json → uses npm
- No lock file → defaults to npm

All publishing operations use the detected package manager automatically.

$3

rlsy intelligently decides when to prompt for publishing:

- Private packages ("private": true in package.json) → Skip publishing
- Package exists on npm AND user has write access → Prompt to publish
- Package doesn't exist → Ask if you want to publish (first release)
- No write access → Skip publishing with clear message

$3

Before publishing, rlsy validates:

- ✓ Authentication via npm whoami (or yarn whoami, pnpm whoami)
- ✓ Version doesn't already exist on registry
- ✓ Package name is valid (including scoped packages like @scope/package)
- ✓ User has write access to the package

$3

When you run rlsy, the publishing happens in this order:

1. Update version files (package.json, etc.)
2. Create git commit and tags
3. Publish to npm (if enabled and confirmed)
4. Push to git remote
5. Create GitLab/GitHub release

Why publish before push? This order makes error recovery easier. If publishing fails, you can fix the issue and retry without having already pushed tags to git.

$3

`yaml
npm:
enabled: true # Auto-detect from package.json (default: true)
publish: true # Actually publish to registry (default: true)
validateAuth: true # Check authentication early (default: true)
checkExisting: true # Check if package exists on registry (default: true)
previewContents: true # Show files in dry-run (default: true)
continueOnError: false # Abort on publish failure (default: false)
tag: latest # npm dist-tag (default: 'latest')
`

$3

Use npm distribution tags to publish pre-releases:

`yaml
npm:
tag: next # For pre-releases
`

- latest - Stable releases (default)
- next - Pre-releases, beta versions
- beta - Beta releases
- Custom tags for your workflow

$3

rlsy uses your existing package manager authentication:

`bash


npm

npm login

yarn

yarn login

pnpm

pnpm login
`

For CI/CD, use the NPM_TOKEN environment variable:

`bash


.gitlab-ci.yml or GitHub Actions


export NPM_TOKEN=your-token-here
`

$3

In dry-run mode, rlsy shows what would be published:

`bash
rlsy --dry-run
`

Output includes:

- Package name and version
- Registry URL
- Files that would be published (from npm pack --dry-run)
- Publish command that would run
- Any warnings or restrictions

$3

rlsy automatically handles scoped packages (@scope/package-name) and sets the correct access level based on your publishConfig in package.json:

`json
{
"name": "@myorg/my-package",
"publishConfig": {
"access": "public"
}
}
`

$3

To disable npm publishing entirely:

`yaml
npm:
enabled: false
`

Or skip it for specific releases by answering "No" when prompted.

$3

If publishing fails, rlsy provides clear, actionable error messages:

- Not authenticated: "Run npm login to authenticate"
- Version already exists: "Version 1.2.3 already published. Use a different version."
- No permissions: "You don't have write access to this package"
- Network errors: "Failed to reach npm registry. Check your connection."

GitLab Integration

rlsy uses the GitLab CLI (glab) to create releases.

$3

1. Install glab:

`bash


macOS

brew install glab

Linux

See: https://gitlab.com/gitlab-org/cli#installation

`

2. Authenticate:

`bash
glab auth login
`

$3

When you run rlsy, it will automatically:

1. Create annotated git tags
2. Push tags to remote
3. Create a GitLab release with:
- Release title: Release v{version}
- Release notes: Your curated changelog
- Associated tag: Project version tag
- Branch: Configured release branch (default: main)

$3

`yaml
gitlab:
createRelease: true
releaseBranch: main
`

Disable GitLab release creation:

`yaml
gitlab:
createRelease: false
`

Dry-Run Mode

Dry-run mode lets you preview all changes before executing them. This is perfect for:

- Verifying changes before release
- Testing configuration
- CI/CD pipeline validation
- Learning how rlsy works

$3

`bash
rlsy --dry-run
`

$3

#### 1. Configuration Summary

`
📋 Configuration
Config: .rlsyrc.yaml
Branch: main
Current Version: v1.2.3
`

#### 2. Proposed Versions

`
🎯 Proposed Versions
Project: v1.3.0 (minor)
Helm Chart (my-app): 1.3.0
`

#### 3. Generated Changelog

`
📝 Generated Changelog
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


[1.3.0] - 2025-10-07

$3

- User authentication with OAuth2
- Rate limiting middleware

$3

- Memory leak in connection pool
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
`

#### 4. File Changes (Unified Diffs)

`
📄 File Changes

--- package.json
+++ package.json
@@ -1,5 +1,5 @@
{
"name": "my-app",
- "version": "1.2.3",
+ "version": "1.3.0",
"description": "..."
}
`

#### 5. Git Operations

`
🏷️ Git Operations

Commit:
Message: "chore: release v1.3.0"
Files:
- package.json
- CHANGELOG.md

Annotated Tags:
- v1.3.0 (project)
Message: "Release v1.3.0..."
`

#### 6. Remote Operations

`
🚀 Remote Operations

Push:
Branch: main
Tags: v1.3.0
Remote: origin

GitLab Release:
Title: "Release v1.3.0"
Tag: v1.3.0
`

$3

In dry-run mode:

- ✓ All validation checks are performed
- ✓ Changelog is generated and displayed (no editor)
- ✓ File diffs are shown
- ✗ No files are modified
- ✗ No git commits or tags are created
- ✗ Nothing is pushed to remote
- ✗ No GitLab releases are created

Examples

$3

A typical Node.js project with automated releases:

Project Structure:

`
my-app/
├── package.json
├── CHANGELOG.md
├── src/
└── .rlsyrc.yaml
`

Configuration (.rlsyrc.yaml):

`yaml
project:
enabled: true
tagFormat: v{version}
versionFiles:
- file: package.json
jsonPath: version

changelog:
file: CHANGELOG.md
`

Usage:

`bash


Create a release

rlsy

Preview first

rlsy --dry-run
`

$3

A project containing only Helm charts:

Project Structure:

`
helm-charts/
├── helm/
│ └── my-app/
│ ├── Chart.yaml
│ └── values.yaml
├── CHANGELOG.md
└── .rlsyrc.yaml
`

Configuration (.rlsyrc.yaml):

`yaml
project:
enabled: false

helm:
enabled: true
autoDetect: true
directory: helm
`

$3

A Node.js application with Helm chart deployment:

Project Structure:

`
full-stack-app/
├── package.json
├── src/
├── helm/
│ └── my-app/
│ ├── Chart.yaml
│ └── values.yaml
├── Dockerfile
├── CHANGELOG.md
└── .rlsyrc.yaml
`

Configuration (.rlsyrc.yaml):

`yaml
project:
enabled: true
versionFiles:
- file: package.json
jsonPath: version
- file: Dockerfile
pattern: 'LABEL version="([^"]+)"'
replacement: 'LABEL version="{version}"'

helm:
enabled: true
charts:
- name: my-app
path: helm/my-app
versionFiles:
- file: helm/my-app/values.yaml
yamlPath: image.tag
`

Workflow:

1. Run rlsy
2. Select Helm chart version (e.g., 2.1.0)
3. Select project version (e.g., 1.5.3)
4. Edit changelog in your editor
5. Confirm and release

Result:

- Chart.yaml → version: 2.1.0, appVersion: "1.5.3"
- package.json → version: "1.5.3"
- values.yaml → image.tag: "1.5.3" (chart version used)
- Dockerfile → LABEL version="1.5.3"
- Git tags: v1.5.3 and my-app-2.1.0

$3

Publish a Node.js package to npm with automated versioning:

Project Structure:

`
my-npm-package/
├── package.json
├── src/
├── tests/
├── CHANGELOG.md
└── .rlsyrc.yaml
`

Configuration (.rlsyrc.yaml):

`yaml
project:
enabled: true
tagFormat: v{version}
versionFiles:
- file: package.json
jsonPath: version

npm:
enabled: true
publish: true
tag: latest

git:
pushTags: true
pushCommits: true

gitlab:
createRelease: true
`

Workflow:

`bash


Preview the release (including what would be published)

rlsy --dry-run

Create release and publish

rlsy
`

What happens:

1. Prompts for version (e.g., 1.2.3 → 1.3.0)
2. Generates and opens changelog in editor
3. Updates package.json version
4. Creates git commit: Release 1.3.0
5. Creates git tag: v1.3.0
6. Publishes to npm using detected package manager
7. Pushes commits and tags to remote
8. Creates GitLab release

Package managers:

- With pnpm-lock.yaml → runs pnpm publish
- With yarn.lock → runs yarn publish (or npm publish for yarn 2+)
- With package-lock.json → runs npm publish

$3

Update version across multiple files:

Configuration (.rlsyrc.yaml):

`yaml
project:
versionFiles:
- file: package.json
jsonPath: version
- file: VERSION
type: plain
- file: README.md
pattern: 'Version\s+v([0-9.]+)'
replacement: Version v{version}
- file: src/version.ts
pattern: 'export const VERSION = "''["'']'
replacement: "export const VERSION = '{version}'"
- file: docs/installation.md
pattern: 'download\/v([0-9.]+)\/'
replacement: download/v{version}/
`

Troubleshooting

$3

Error:

`
Error: Working directory has uncommitted changes
`

Solution:
Commit or stash your changes before running rlsy:

`bash


Commit changes

git add .
git commit -m "Your commit message"

Or stash changes

git stash
`

$3

Error:

`
Error: $EDITOR environment variable is not set
`

Solution:
Set your preferred editor:

`bash


Temporarily

export EDITOR=vim

Permanently (add to ~/.bashrc or ~/.zshrc)

echo 'export EDITOR=vim' >> ~/.bashrc
`

$3

Error:

`
Error: glab authentication required
`

Solution:
Authenticate with GitLab:

`bash
glab auth login
`

$3

Warning:

`
Warning: No previous version tags found, defaulting to 0.0.0
`

Solution:
This is normal for first release. rlsy will create the first tag.

$3

Error:

`
Error: Pattern not found in file: README.md
`

Solution:
Check your regex pattern matches the actual file content:

`bash


Test pattern (dry-run shows what will match)


rlsy --dry-run --verbose
`

$3

Error:

`
Error: Invalid semantic version: 1.2
`

Solution:
Use valid semver format: MAJOR.MINOR.PATCH (e.g., 1.2.0)

FAQ

$3

Yes! rlsy supports both GitHub (via gh CLI) and GitLab (via glab CLI). The tool automatically detects your remote and uses the appropriate CLI tool. Both platforms can be enabled simultaneously if you have multiple remotes.

$3

Yes! rlsy automatically detects your package manager from lock files (pnpm-lock.yaml, yarn.lock, or package-lock.json) and uses the appropriate command for all operations including publishing. It supports npm, yarn (both 1.x and 2+), and pnpm.

$3

Not yet. Monorepo support is planned for a future version.

$3

The changelog follows Keep a Changelog format. You can customize commit type mappings, but the overall structure is fixed.

$3

Set gitlab.createRelease: false in your config:

`yaml
gitlab:
createRelease: false
`

$3

Yes! Use dry-run mode for validation and pass responses via stdin for automation (note: CI/CD automation support is still experimental).

$3

If you exit the editor without saving, rlsy will prompt you to:

- Use the changelog as-is
- Edit again
- Cancel the release

$3

Yes, configure it:

`yaml
changelog:
file: docs/CHANGELOG.md
`

$3

rlsy automatically prompts for both versions. The Helm chart version goes to Chart.yaml → version, and the app version goes to Chart.yaml → appVersion.

Development

$3

`bash


Run all tests

npm test

Run with coverage

npm run test:coverage

Watch mode

npm test -- --watch
`

$3

`bash


Lint code

npm run lint

Format code

npm run format

Check formatting

npm run format:check
`

$3

`
rlsy/
├── src/
│ ├── cli.js # Entry point, argument parsing
│ ├── commands/
│ │ └── release.js # Main release command
│ ├── core/
│ │ ├── config.js # Configuration loading/validation
│ │ ├── git.js # Git operations wrapper
│ │ ├── gitlab.js # GitLab/glab operations
│ │ ├── helm.js # Helm chart detection/parsing
│ │ ├── version.js # Version detection/validation
│ │ ├── versionFiles.js # Version file updates
│ │ └── changelog.js # Changelog generation/parsing
│ ├── utils/
│ │ ├── editor.js # Editor invocation
│ │ ├── prompts.js # User interaction
│ │ ├── validation.js # Input validation
│ │ └── display.js # Dry-run output formatting
│ └── templates/
│ └── changelog.js # Changelog template generation
├── tests/ # Test files
├── .rlsyrc.yaml # Example config
└── package.json
``

$3

Contributions are welcome! Please:

1. Fork the repository
2. Create a feature branch
3. Make your changes
4. Add tests for new functionality
5. Ensure all tests pass
6. Submit a pull request

License

MIT License - see LICENSE file for details

Credits

Created and maintained by the rlsy team.

Inspired by:

- Keep a Changelog
- Semantic Versioning
- Conventional Commits

Support

- Issues: GitLab Issues
- Documentation: Full Documentation

---

Made with ❤️ by developers, for developers. Release made real easy.