CLI tool for streamlining the release process with automated changelog generation and version management
- 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
rlsy requires the following tools to be installed:
- Node.js >= 18.0.0
- git (for version control operations)
- glab (GitLab CLI) - Installation instructions
``bashInstall globally via npm
npm install -g 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 initOr 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 status2. Run rlsy
rlsy3. 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 initInitialize with auto-detected defaults
rlsy init --yesCreate a release (interactive)
rlsy
rlsy releasePreview changes without executing
rlsy --dry-runUse custom configuration file
rlsy --config .rlsy/production.yamlEnable verbose logging for debugging
rlsy --verboseCombine 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 initAuto-accept detected defaults
rlsy init --yesOverwrite existing config without confirmation
rlsy init --forcePreview 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 writingAuto-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.yamlConfiguration 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.mdGit configuration
git:
pushTags: true
pushCommits: trueGitLab 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 creationNote: 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 continueIn 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 changelogIn 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: falsehelm:
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*([^]+)'{version}'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 npmAll 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 loginyarn
yarn loginpnpm
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 glabLinux
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 OperationsCommit:
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 OperationsPush:
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: versionchangelog:
file: CHANGELOG.md
`Usage:
`bash
Create a release
rlsyPreview 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: falsehelm:
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 releaseResult:
-
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: versionnpm:
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-runCreate 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 releasePackage 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=vimPermanently (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 testRun with coverage
npm run test:coverageWatch mode
npm test -- --watch
`$3
`bash
Lint code
npm run lintFormat code
npm run formatCheck 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
``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
MIT License - see LICENSE file for details
Created and maintained by the rlsy team.
Inspired by:
- Keep a Changelog
- Semantic Versioning
- Conventional Commits
- Issues: GitLab Issues
- Documentation: Full Documentation
---
Made with ❤️ by developers, for developers. Release made real easy.