Overview
The hotfix release workflow:- Trigger: Automatically when hotfix PR is merged to main or release branches
- Condition: Only runs for merged pull requests
- Quality Checks: Code quality validation before draft creation
- Automatic: No manual intervention required
- Fast: 15-minute timeout for quick hotfix releases
Workflow Flowchart
Workflow Configuration
The hotfix release draft workflow is defined in.github/workflows/hotfix-release-draft.yaml:
Hotfix Process
1. PR Merge Trigger
When a hotfix PR is merged:- Workflow is automatically triggered
- Only runs if PR was merged (not just closed)
- Works for PRs merged to
mainorrelease/**branches - Uses the base branch as both source and target
2. Setup Project
- Authenticates using GitHub App
- Checks out code from the base branch (where PR was merged)
- Sets up Python environment
- Resolves project metadata
3. Action Pinning Check
- Validates GitHub Actions are pinned to SHA versions
- Ensures security compliance
- Quick validation step
4. Code Quality Checks
- Runs pylint for code quality
- Executes pytest for unit tests
- Runs hadolint for Dockerfile validation
- Ensures hotfix doesn’t introduce quality issues
5. Create Release Draft
- Creates release draft for the base branch
- Updates version (typically patch version)
- Generates release notes
- Creates GitHub release draft
When to Use Hotfix Releases
Hotfix releases are appropriate for:- Critical Bug Fixes: Urgent fixes that need immediate release
- Security Patches: Security vulnerabilities requiring quick resolution
- Production Issues: Fixes for production issues affecting users
- Emergency Fixes: Time-sensitive fixes that can’t wait for regular release cycle
Hotfix Workflow Characteristics
Automatic Triggering
- No manual intervention required
- Automatically runs when hotfix PR is merged
- Streamlined process for urgent fixes
Fast Execution
- 15-minute timeout for quick turnaround
- Focused quality checks
- Efficient release draft creation
Branch-Specific
- Creates release draft for the branch where PR was merged
- Supports both main and release branches
- Maintains branch-specific versioning
Reusable Components Used
This workflow leverages:- setup-project: Sets up Python environment and resolves metadata
- check-action-pinning: Validates GitHub Actions security
- code-quality: Runs code quality checks
- create-release-draft: Creates release draft with versioning
Hotfix Release Process
Steps
- Create Hotfix Branch: Create a branch from the target release branch
- Fix Issue: Implement the hotfix
- Create PR: Open pull request to main or release branch
- PR Validation: PR checks run automatically
- Merge PR: Merge the hotfix PR
- Auto-Trigger: Hotfix release workflow automatically starts
- Review Draft: Review the created release draft
- Publish: Publish the release when ready
Version Management
Hotfix releases typically:- Increment patch version (e.g.,
1.2.3→1.2.4) - Maintain compatibility with base release
- Include hotfix-specific release notes
Best Practices
- Target Correct Branch: Merge hotfix to the appropriate branch (main or release)
- Quick Quality Checks: Ensure code quality checks pass quickly
- Clear PR Description: Include clear description of the hotfix
- Test Thoroughly: Test hotfix before merging
- Review Release Draft: Review auto-generated release notes
Troubleshooting
Common Issues
-
Workflow Not Triggering
- Ensure PR was merged (not just closed)
- Verify PR was merged to main or release branch
- Check workflow file exists and is correct
-
Timeout Issues
- Workflow has 15-minute timeout
- Optimize code quality checks if needed
- Review workflow logs for bottlenecks
-
Quality Check Failures
- Fix code quality issues before merging
- Address pylint, pytest, or hadolint failures
- Ensure hotfix doesn’t introduce new issues
-
Release Draft Creation Failures
- Verify release-drafter configuration
- Check GitHub App credentials
- Ensure proper repository permissions
Verification
- Check workflow logs in GitHub Actions
- Verify release draft was created
- Review code quality check results
- Confirm version numbers are correct