This document explains the automated release workflow for the VS Code TinyPNG extension.
The release workflow automates the entire release process:
- Analyzes commits using conventional commit standards
- Determines the appropriate semantic version bump (major, minor, patch)
- Updates
package.jsonwith the new version - Generates/updates
CHANGELOG.mdautomatically - Creates a Git tag for the release
- Publishes the extension to the VS Code Marketplace
- Creates a GitHub Release with release notes
To enable automatic publishing to the VS Code Marketplace, you need to set up a Personal Access Token:
-
Create a Personal Access Token:
- Go to https://dev.azure.com/
- Navigate to User Settings > Personal Access Tokens
- Click "New Token"
- Name:
vscode-tinypng-release - Organization:
All accessible organizations - Scopes: Select
Marketplace>Manage - Click "Create"
-
Add the token to GitHub Secrets:
- Go to your GitHub repository
- Navigate to Settings > Secrets and variables > Actions
- Click "New repository secret"
- Name:
VSCE_PAT - Value: Paste your Azure DevOps Personal Access Token
- Click "Add secret"
The workflow uses GITHUB_TOKEN which is automatically provided by GitHub Actions. No additional setup required.
The workflow uses conventional commits to automatically determine the version bump type:
<type>(<scope>): <subject>
<body>
<footer>
| Commit Type | Version Bump | Example |
|---|---|---|
feat: |
minor (0.x.0) | feat: add WebP compression support |
fix: |
patch (0.0.x) | fix: resolve file encoding issue |
BREAKING CHANGE: or ! |
major (x.0.0) | feat!: remove deprecated API |
chore:, docs:, refactor: |
patch (0.0.x) | chore: update dependencies |
Minor version bump (new feature):
feat: add queue system for batch compression
Implements a concurrent queue system that processes
multiple images efficiently with configurable concurrency.
Patch version bump (bug fix):
fix: prevent duplicate compressions in queue
Fixes an issue where the same file could be added
to the compression queue multiple times.
Major version bump (breaking change):
feat!: redesign compression API
BREAKING CHANGE: The compression service now requires
async/await syntax instead of callbacks.
-
Navigate to GitHub Actions:
- Go to your repository on GitHub
- Click on the "Actions" tab
- Select "Release" workflow from the left sidebar
-
Run the workflow:
- Click "Run workflow" button
- Configure options:
- Branch: Select the branch to release from (usually
developormain) - Version bump type: Leave empty for auto-detection or manually select major/minor/patch
- Dry run: Check this to test the workflow without actually publishing
- Branch: Select the branch to release from (usually
- Click "Run workflow"
- Empty (default): Automatically detect version bump from commits
- major: Force a major version bump (e.g., 1.0.0 → 2.0.0)
- minor: Force a minor version bump (e.g., 1.0.0 → 1.1.0)
- patch: Force a patch version bump (e.g., 1.0.0 → 1.0.1)
- false (default): Execute full release including publishing
- true: Test the workflow without publishing or pushing changes
The workflow performs the following steps:
-
Checkout & Setup
- Checks out the repository with full history
- Sets up Node.js 22 with npm caching
-
Build & Test
- Installs dependencies
- Compiles TypeScript
- Runs the test suite
-
Version Analysis
- Retrieves current version from
package.json - Gets the latest Git tag
- Analyzes commits since last tag
- Determines version bump type (unless manually specified)
- Calculates new version number
- Retrieves current version from
-
Update Files
- Updates
package.jsonwith new version - Updates
package-lock.json - Generates/updates
CHANGELOG.mdusing conventional changelog format
- Updates
-
Commit & Tag
- Commits version bump and changelog changes
- Creates a Git tag (e.g.,
v1.4.0) - Pushes changes and tags to GitHub
-
Package & Publish
- Packages the extension as
.vsixfile - Publishes to VS Code Marketplace (if
VSCE_PATis configured)
- Packages the extension as
-
GitHub Release
- Extracts relevant changelog section
- Creates a GitHub Release with release notes
- Attaches
.vsixfile to the release
Always use conventional commit messages for your commits. This ensures accurate version bumping.
# Good
git commit -m "feat: add new compression algorithm"
git commit -m "fix: resolve memory leak in queue service"
# Bad
git commit -m "updated stuff"
git commit -m "bug fixes"Before doing an actual release, run the workflow with dry run enabled to verify:
- Version bump is correct
- CHANGELOG looks good
- No errors in the process
Maintain a stable develop branch and trigger releases from it. This ensures:
- All tests pass
- Code is reviewed
- Features are complete
After the workflow completes, review the generated CHANGELOG.md to ensure:
- All important changes are documented
- Formatting is correct
- No sensitive information is exposed
Error: VSCE_PAT secret not set
- Solution: Add
VSCE_PATsecret to repository settings (see Setup Requirements)
Error: Authentication failed
- Solution: Verify your Personal Access Token is valid and has Marketplace permissions
Issue: Workflow runs but version stays the same
- Cause: No conventional commits found since last tag
- Solution: Ensure commits follow conventional commit format, or manually specify version type
Issue: Workflow fails at test step
- Cause: Breaking changes or failing tests in the codebase
- Solution: Fix tests before releasing, or skip tests (not recommended)
Error: failed to push some refs
- Cause: Protected branch or outdated local branch
- Solution: Ensure branch protection rules allow GitHub Actions to push
If the automated workflow fails, you can still release manually:
# 1. Update version
npm version patch|minor|major
# 2. Update CHANGELOG
conventional-changelog -p angular -i CHANGELOG.md -s
# 3. Commit and tag
git add .
git commit -m "chore(release): vX.Y.Z"
git tag vX.Y.Z
# 4. Push
git push origin develop
git push origin --tags
# 5. Publish
vsce login
vsce publish
# 6. Create GitHub release manuallyMonitor workflow runs in the Actions tab:
- Green checkmark: Successful release
- Red X: Failed release (check logs)
- Yellow dot: In progress
Click on a workflow run to see detailed logs for each step.
Configure GitHub notifications to receive alerts when workflows complete or fail.
- Never commit
VSCE_PATor other secrets to the repository - Use GitHub Secrets for sensitive tokens
- Review workflow permissions regularly
- Audit published versions for security issues
If you encounter issues with the release workflow:
- Check the workflow logs in GitHub Actions
- Review this documentation
- Check conventional-changelog and vsce documentation
- Open an issue in the repository