Skip to content

Pullpiri Release Management

Overview

Pullpiri uses GitHub Actions for automated CI/CD pipeline management of the release process. When a version tag is pushed to the repository, the workflow automatically:

  1. Validates the codebase (formatting, linting, tests)
  2. Validates documentation and configuration
  3. Generates code coverage and compliance reports
  4. Compiles release artifacts and binaries
  5. Publishes assets to GitHub Release

This automated approach ensures consistent, high-quality releases with comprehensive validation at each stage.

Release Process

Versioning

Pullpiri follows semantic versioning with the format: vX.Y.Z

  • X: Major version (breaking changes)
  • Y: Minor version (new features, backward compatible)
  • Z: Patch version (bug fixes)

Examples: v1.0.0, v1.1.0, v1.2.3

Creating a Release

To create a new release:

# Navigate to the project directory
cd /path/to/pullpiri

# Create a version tag (e.g., v1.0.0)
git tag v1.0.0

# Push the tag to trigger the release workflow
git push origin v1.0.0

Important: Tags must start with v and follow the semantic versioning format. Invalid tags will not trigger the release workflow.

Once the tag is pushed, GitHub Actions automatically initiates the release pipeline. You can monitor progress in the Actions tab of the GitHub repository.

Automated Release Pipeline

The release pipeline consists of 5 sequential stages that must all succeed before publishing:

Stage 1: Rust Codebase Validation (run-rust-ci)

Validates all Rust code against project standards:

  • Formatting Check (cargo fmt --check): Verifies code follows Rust formatting rules
  • Linting Check (cargo clippy): Identifies code quality issues and style violations
  • Unit Tests (cargo test): Runs all unit tests across components
  • server (apiserver, settingsservice, etc.)
  • player (filtergateway, actioncontroller, statemanager)
  • tools (pirictl, rocksdb-inspector, idl2rs)
  • common (shared utilities and gRPC definitions)

Output: fmt_summary.md, clippy_summary.md, test_summary.xml

Stage 2: Documentation Validation (run-doc-lint)

Validates markdown files and documentation formatting:

  • Markdown syntax checking
  • Link validation
  • Formatting consistency

Failure Impact: Prevents release if documentation standards are not met.

Stage 3: YAML Configuration Validation (run-yaml-validation)

Validates all YAML files in the repository:

  • GitHub Actions workflows (.github/workflows/*.yml)
  • Configuration files
  • Example scenarios

Failure Impact: Prevents release if any YAML is malformed.

Stage 4: License & Dependency Check (run-license-report)

Generates open source license compliance report:

  • Scans all Rust dependencies using cargo-about
  • Validates against the deny allowlist (.cargo/deny.toml)
  • Detects license violations or restricted dependencies
  • Generates HTML license report

Output: license-report.html, deny_summary.md

Failure Impact: Prevents release if prohibited dependencies are detected.

Stage 5: Artifact Collection & Publication (tag_release_artifacts)

Collects all artifacts from prior stages and publishes to GitHub Release:

  • Downloads all generated reports from previous stages
  • Compiles nodeagent binaries (AMD64, ARM64)
  • Creates documentation archive
  • Uploads all files as GitHub Release assets
  • Triggers automatic release notes generation

Release Artifacts

All artifacts generated by the release pipeline are automatically uploaded to the GitHub Release page.

Code Coverage Reports

Generated for each component:

  • code-coverage-server.html - API Server coverage
  • code-coverage-tools.html - Tools (pirictl, rocksdb-inspector) coverage
  • code-coverage-common.html - Common utilities coverage

Validation Reports

  • fmt_summary.md - Formatting check results
  • clippy_summary.md - Lint/code quality check results
  • test_summary.xml - Unit test results (JUnit format)
  • deny_summary.md - Dependency and license check results

License Report

  • license-report.html - Complete open source license documentation

Compiled Binaries

  • nodeagent-linux-amd64 - NodeAgent binary for Linux x86_64
  • nodeagent-linux-arm64 - NodeAgent binary for Linux ARM64

Documentation & Scripts

  • README.md - Main project documentation
  • coding-rule.md - Coding guidelines and standards
  • release.yml - Release workflow definition
  • install_nodeagent.sh - NodeAgent installation script
  • node_ready_check.sh - Node readiness verification script
  • doc-archive.tar.gz - Complete documentation folder archive

Release Validation

The release pipeline implements comprehensive validation at each stage:

Pre-release Checks

Before the release is published, the following must pass:

  1. All Rust code passes formatting, linting, and tests
  2. All documentation is valid Markdown with proper formatting
  3. All configuration files have valid YAML syntax
  4. All dependencies are approved and properly licensed
  5. Code coverage is generated for quality assessment

Failure Handling

If any stage fails:

  1. The workflow immediately stops and subsequent stages are skipped
  2. The release is not published to GitHub
  3. Detailed error logs are available in the Actions tab
  4. Developers must fix the issues and push a new tag to retry

Monitoring Release Status

Watch the release pipeline progress:

  1. Go to the GitHub repository
  2. Click the Actions tab
  3. Find the workflow triggered by your version tag
  4. Monitor the status of each stage
  5. Review detailed logs for any failures

Release Notes

GitHub automatically generates release notes based on:

  • Commits merged since the last release
  • Pull request titles and descriptions
  • Contributor credits

Release notes can be manually edited after the release is published on the GitHub Release page.