| sidebar_position | 4 |
|---|
Understanding CI Dokumentor's CI/CD pipeline helps you contribute effectively and debug issues. This guide covers our entire automation setup from testing to deployment.
CI Dokumentor uses GitHub Actions for continuous integration and deployment with a multi-stage pipeline:
- Continuous Integration - Code quality, testing, and validation
- Docker Building - Multi-architecture container images
- Release Management - Automated releases and documentation
- Documentation Deployment - Automated documentation updates
.github/workflows/
├── __shared-ci.yml # Reusable CI tasks
├── main-ci.yml # Main branch CI/CD
├── pull-request-ci.yml # PR validation
├── semantic-pull-request.yml # PR title validation
├── greetings.yml # Welcome new contributors
├── stale.yml # Stale issue management
└── need-fix-to-issue.yml # Link PRs to issuesgraph TD
A[pull-request-ci.yml] --> B[__shared-ci.yml]
C[main-ci.yml] --> B
C --> D[Docker Build]
C --> E[Release]
C --> F[Documentation Update]
C --> G[NPM Publish]
B --> H[Linting]
B --> I[Node.js CI]
B --> J[Package Testing]
I --> K[Build]
I --> L[Test]
I --> M[Coverage]
J --> N[NPM Tarball Creation]
J --> O[CLI Functionality Testing]
J --> P[Package Validation]
- Super-Linter - Multi-language linting
- ESLint - TypeScript/JavaScript code quality
- Prettier - Code formatting validation
- Markdownlint - Documentation quality
- YAML Lint - Configuration file validation
- Dependencies - pnpm install with caching
- Build - nx build all packages
- Test - Comprehensive test suite with coverage
- Security - Dependency vulnerability scanning
- Coverage Report - Codecov integration
- CLI Build Verification - Ensure CLI binary is properly built
- Package Creation - Create npm tarball using
npm pack - Global Installation - Install package globally from tarball
- Command Testing - Test version, help, and generate commands
- Output Validation - Verify documentation generation works
- Artifact Upload - Upload tested package for later publishing
-
Trigger Conditions:
- Pull request opened/updated
- Merge queue integration
- Branch protection rules
-
Validation Steps:
- Code quality checks
- Unit and integration tests
- Build verification
- Security scanning
- Documentation validation
-
Status Checks:
- All checks must pass for merge
- Failed checks block merging
- Coverage thresholds enforced
To pass CI, your PR must:
- ✅ Pass all linting - No ESLint or Prettier errors
- ✅ Pass all tests - 100% test success rate
- ✅ Meet coverage thresholds - Maintain or improve coverage
- ✅ Build successfully - All packages compile
- ✅ Have no security vulnerabilities - Pass security scans
- ✅ Follow semantic PR titles - Use conventional commit format
- Same as PR workflow
- Full validation pipeline
- Must pass for subsequent jobs
- Multi-architecture builds - AMD64 and ARM64
- Production optimization - Minimal image size
- Registry push - GitHub Container Registry
- Tag management - Latest, version tags, and SHA tags
- Security scanning - Container vulnerability assessment
- Tag-triggered - Only runs on Git tag pushes
- Artifact reuse - Publishes tested package tarball
- Provenance - Includes npm provenance for security
- Scoped package - Published as
@ci-dokumentor/cli - Public access - Available for global installation
- Readme generation - Auto-update repository readme
- Documentation updates - Generate action/workflow docs
- Automated PRs - Create and merge documentation updates
- GitHub App authentication - Secure token management
Images are published to GitHub Container Registry:
- Registry:
ghcr.io/hoverkraft-tech/ci-dokumentor/cli - Tags:
latest- Latest stable releasemain- Latest main branch build1.0.0- Specific version tagssha-abcd123- Commit SHA tags
CI Dokumentor follows semantic versioning:
- Major (1.0.0) - Breaking changes
- Minor (0.1.0) - New features (backward compatible)
- Patch (0.0.1) - Bugfixes
The release process is triggered by:
- Manual workflow dispatch
- Tag creation
- Scheduled releases (weekly)
- Version Detection - Parse version from tags or package.json
- Changelog Generation - Auto-generate from commit history
- Asset Creation - Build and package artifacts
- Docker Image - Build and tag container images
- Documentation - Update documentation and readme
- GitHub Release - Create release with notes and assets
- NPM Publish - Publish CLI package to npm registry (triggered on tags)
- Tag Trigger - Automatically triggered on Git tag pushes
- Artifact Reuse - Publishes the exact tarball that was tested
- Provenance - Includes npm provenance for supply chain security
- Public Access - Published as public scoped package
@ci-dokumentor/cli
The two-stage approach ensures that the published package works correctly in real-world scenarios before it reaches the npm registry.
Each release includes:
- Source code - Tarball and ZIP
- Docker images - Multi-architecture containers
- Documentation - Generated docs archive
- NPM Package - Standalone CLI package with bundled dependencies
The pipeline automatically maintains documentation:
This generates:
- Action documentation - From action.yml files
- Workflow documentation - From .github/workflows/*.yml
- API documentation - From code comments
- Badge updates - CI status, coverage, version badges
Future implementation will include:
- Docusaurus build - Static site generation
- GitHub Pages deployment - Automated hosting
- Documentation versioning - Version-specific docs
- Search integration - Full-text search capability
- Dependabot - Automated dependency updates
- Security advisories - GitHub security scanning
- Vulnerability assessment - Regular security audits
- License compliance - OSS license validation
- GitHub Secrets - Encrypted secret storage
- GitHub Apps - Secure authentication
- Token rotation - Regular credential updates
- Least privilege - Minimal required permissions
- Base image scanning - Alpine Linux security updates
- Non-root user - Restricted container execution
- Multi-stage builds - Minimal attack surface
- SBOM generation - Software bill of materials
- Test coverage - Minimum 80% coverage
- Linting standards - Zero-warning policy
- Security scans - No high/critical vulnerabilities
- License validation - OSS license compatibility
- All changes logged - Complete Git history
- PR reviews required - No direct pushes to main
- Deployment tracking - Release and deployment logs
- Access controls - GitHub permissions management
- Build success rate - Target: >95%
- Test execution time - Target: <5 minutes
- Docker build time - Target: <10 minutes
- Coverage trends - Maintain or improve
- Automatic retries - Transient failure recovery
- Failure notifications - Slack/email alerts
- Roll-back procedures - Quick recovery processes
- Post-mortem analysis - Root cause identification
- Dependency freshness - Regular updates
- Security patches - Timely vulnerability fixes
- Documentation currency - Up-to-date documentation
- Performance benchmarks - Regular performance testing
- Registry availability - Container registry uptime
- GitHub Actions quota - Usage monitoring
- Storage utilization - Artifact storage management
- Performance metrics - Build and test performance
# Local test reproduction
pnpm test
# Specific package testing
pnpm test --filter @ci-dokumentor/core
# Debug test failures
pnpm test -- --verbose# Local build reproduction
pnpm build
# Clean and rebuild
rm -rf packages/*/dist
pnpm build
# Debug build issues
pnpm build --verbose# Local Docker build
docker build -f docker/Dockerfile .
# Debug Docker build
docker build --no-cache -f docker/Dockerfile .
# Multi-platform build testing
docker buildx build --platform linux/amd64,linux/arm64 -f docker/Dockerfile .-
Enable debug logging:
env: ACTIONS_RUNNER_DEBUG: true ACTIONS_STEP_DEBUG: true
-
Use workflow dispatch for testing
-
Check job logs for detailed output
-
Validate permissions and secrets
# Simulate CI environment
export CI=true
export NODE_ENV=test
# Run CI commands locally
pnpm install --frozen-lockfile
pnpm build
pnpm test:ci
pnpm lintIf you encounter CI issues:
- Check recent workflow runs - Look for patterns
- Review job logs - Find specific error messages
- Test locally - Reproduce the issue
- Ask for help - GitHub discussions or issues
- Check status pages - GitHub Actions status
When modifying workflows:
- Test in a fork first
- Use workflow_dispatch for testing
- Follow security best practices
- Document changes in PR description
- Get review from maintainers
new-job:
needs: ci
runs-on: ubuntu-latest
permissions:
contents: read # Minimal permissions
steps:
- uses: actions/checkout@v4
- name: Your new step
run: echo "New functionality"- Use pinned action versions with SHA hashes
- Minimize permissions to required only
- Validate inputs and outputs
- Avoid exposing secrets in logs
- Use official actions when possible
- Contributing Guidelines - How to contribute
- Development Setup - Local development environment
- Testing Guide - Testing practices and tools
- Docker Integration - Docker usage guide