This guide explains how to publish and release the llms.txt Generator GitHub Action.
- Write access to the repository
- Git configured locally
- Node.js 20+ installed
Ensure all changes are committed and tests pass:
cd src
npm test
npm run test:integrationUpdate the version in package.json:
cd src
npm version patch # or minor, or majorThis will:
- Update
package.json - Create a git commit
- Create a git tag
npm run packageThis ensures the dist/ directory is up to date.
git add dist/
git commit -m "chore: update bundle for release"git push origin main
git push origin --tagsThe GitHub Actions workflow will automatically:
- Run all tests
- Build and bundle the action
- Create a GitHub release
- Generate a changelog
- Upload release artifacts
- Update the major version tag (e.g.,
v1)
The action uses semantic versioning with major version tags:
v1.0.0- Specific versionv1- Latest v1.x.x version (auto-updated)
Users can reference the action using:
# Specific version (recommended for production)
uses: your-org/your-repo/src@v1.0.0
# Major version (gets latest v1.x.x)
uses: your-org/your-repo/src@v1
# Latest (not recommended)
uses: your-org/your-repo/src@mainIf you need to create a release manually:
- Go to GitHub repository → Releases
- Click "Draft a new release"
- Choose or create a tag (e.g.,
v1.0.1) - Generate release notes
- Attach the bundled action archive
- Publish release
To make the action discoverable in GitHub Marketplace:
-
Ensure
action.ymlhas proper metadata:name: Unique action namedescription: Clear descriptionbranding: Icon and color
-
Go to repository → Releases
-
Edit a release
-
Check "Publish this Action to the GitHub Marketplace"
-
Accept the terms
-
Publish
Follow semantic versioning:
-
Major (v1.0.0 → v2.0.0): Breaking changes
- Changed input/output names
- Removed features
- Changed behavior that breaks existing workflows
-
Minor (v1.0.0 → v1.1.0): New features
- New inputs/outputs
- New functionality
- Backward-compatible changes
-
Patch (v1.0.0 → v1.0.1): Bug fixes
- Bug fixes
- Documentation updates
- Performance improvements
Maintain a CHANGELOG.md file documenting all changes:
# Changelog
## [1.1.0] - 2024-01-15
### Added
- New `exclude-pattern` input for filtering files
- Support for `.mdx` files
### Fixed
- Fixed URL encoding for special characters
## [1.0.0] - 2024-01-01
### Added
- Initial release
- Generate llms.txt and llms-full.txt files
- Support for multiple sections
- Auto-commit functionalityAlways test the action before releasing:
# Run unit tests
npm test
# Run integration tests
npm run test:integration
# Test locally with a real repository
cd /path/to/test-repo
export INPUT_BASE_URL="https://example.com"
export INPUT_PROJECT_NAME="Test"
node /path/to/action/dist/index.jsIf a release has issues:
- Create a new patch release with the fix
- Update the major version tag to point to the fixed version:
git tag -fa v1 -m "Rollback to v1.0.1"
git push origin v1 --forceThe repository includes automated workflows:
-
CI (
.github/workflows/ci.yml): Runs on every push/PR- Unit tests
- Integration tests
- Build verification
- Bundle size check
-
Release (
.github/workflows/release.yml): Runs on tag push- Full test suite
- Build and bundle
- Create GitHub release
- Update major version tag
The action is distributed as:
- Source code: Available in the repository
- Bundled action:
dist/index.js(committed to repo) - Release archive: Attached to GitHub releases
Users can reference the action directly from your repository without needing to clone or build it.
After publishing:
- Monitor GitHub Issues for bug reports
- Respond to questions in Discussions
- Update documentation based on user feedback
- Consider creating example repositories
- Never commit secrets or credentials
- Review dependencies regularly for vulnerabilities
- Use Dependabot for automated dependency updates
- Follow GitHub's security best practices