Add automated release infrastructure for v1.0.0

[Copilot]

Implements complete release automation to enable one-command GitHub releases and PyPI publishing for v1.0.0.

Infrastructure

• GitHub Actions workflow (.github/workflows/release.yml)

  • Triggers on version tags (v*.*.*)
  • Builds packages, extracts CHANGELOG notes, creates GitHub release
  • Optional PyPI publishing via PYPI_API_TOKEN secret

• Release script (scripts/release.sh)

  • Validates prerequisites and repository state
  • Extracts version from pyproject.toml with error handling
  • Creates and pushes annotated tags

Documentation

• RELEASE.md - Complete process guide with troubleshooting
• RELEASE_v1.0.0.md - Quick reference for this release
• HOW_TO_RELEASE.md - Step-by-step maintainer instructions
• .github/RELEASE_INFRASTRUCTURE.md - Technical overview
• .github/RELEASE_TEMPLATE.md - Release notes template

Usage

After merge:

# Automated (recommended)
./scripts/release.sh

# Manual
git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0

The workflow automatically builds packages, generates release with CHANGELOG notes, and publishes to PyPI if configured.

Technical Details

• AWK pattern uses proper variable interpolation for version matching
• Branch name cached to avoid redundant git calls
• Version extraction includes error handling for malformed pyproject.toml
• GitHub Action pinned to v2 for security

Original prompt

1.0.0 versiyonu için tag ve release oluşturarak tanıtmalıyız

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

---

PR Type

Enhancement, Documentation

---

Description

• Add complete automated release infrastructure for v1.0.0

• Create GitHub Actions workflow for tag-triggered releases

• Add comprehensive release documentation and guides

• Implement automated bash script for streamlined releases

• Update CONTRIBUTING.md with release process instructions

---

Diagram Walkthrough

flowchart LR
  A["Git Tag Push<br/>v1.0.0"] -->|triggers| B["GitHub Actions<br/>release.yml"]
  B -->|builds| C["Python Package<br/>wheel + tar.gz"]
  B -->|extracts| D["Release Notes<br/>from CHANGELOG.md"]
  C -->|creates| E["GitHub Release<br/>with assets"]
  D -->|populates| E
  C -->|publishes| F["PyPI<br/>if configured"]
  G["scripts/release.sh"] -->|automates| A
  H["Documentation<br/>RELEASE.md<br/>HOW_TO_RELEASE.md"] -->|guides| G

Loading

File Walkthrough

	Relevant files
Enhancement	release.yml GitHub Actions automated release workflow                                .github/workflows/release.yml New GitHub Actions workflow triggered on version tags matching v*.*.* Builds Python package using python -m build Extracts release notes from CHANGELOG.md using awk Creates GitHub Release with extracted notes and built artifacts Publishes to PyPI if PYPI_API_TOKEN secret is configured +68/-0    release.sh Automated release script with validation checks                    scripts/release.sh New executable bash script to automate release process Validates prerequisites (git, python) and branch status Checks for clean working directory and pulls latest changes Reads version from pyproject.toml and validates tag doesn't exist Creates annotated git tag and pushes to origin Provides colored output and user confirmations +170/-0
Documentation	RELEASE.md Complete release process documentation                                      RELEASE.md Comprehensive release process documentation following Semantic Versioning Detailed workflow steps from preparation through verification Changelog format requirements based on Keep a Changelog standard PyPI configuration instructions for automatic publishing Manual release fallback procedures and troubleshooting guide Release checklist for maintainers +188/-0  HOW_TO_RELEASE.md v1.0.0 release quick start guide                                                  HOW_TO_RELEASE.md Step-by-step guide specifically for creating v1.0.0 release Quick TL;DR section with minimal commands needed Two release options: automated script and manual git commands Detailed monitoring instructions for GitHub Actions and releases Troubleshooting section for common issues PyPI configuration and post-release tasks +213/-0  RELEASE_v1.0.0.md v1.0.0 release quick reference guide                                          RELEASE_v1.0.0.md Quick reference guide tailored for v1.0.0 release Prerequisites checklist confirming version and changelog readiness Two implementation options with step-by-step instructions Explanation of automated workflow steps after tag push Monitoring procedures for Actions, GitHub Release, and PyPI Troubleshooting and post-release task guidance +152/-0  RELEASE_TEMPLATE.md GitHub release description template                                            .github/RELEASE_TEMPLATE.md Template for GitHub release descriptions with placeholder sections Highlights section for main features and changes Installation instructions for PyPI and source installations MCP Server integration setup for Claude Desktop Documentation links and contributor acknowledgment sections Changelog and comparison URL placeholders +71/-0    RELEASE_INFRASTRUCTURE.md Release infrastructure overview and summary                            .github/RELEASE_INFRASTRUCTURE.md Comprehensive overview of entire release infrastructure Detailed descriptions of all added files and their purposes Release workflow explanation for maintainers Configuration requirements and testing validation results Current status confirmation for v1.0.0 readiness Benefits summary and future improvement suggestions +175/-0  CONTRIBUTING.md Add release process section for maintainers                            CONTRIBUTING.md New "Release Process" section added for maintainers Brief overview of release steps and script usage Links to detailed documentation in RELEASE.md Instructions for both automated and manual release methods +11/-0

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Unpinned GitHub Actions Description: The workflow uses third-party GitHub Actions (notably softprops/action-gh-release@v1 and also actions/checkout@v4 / actions/setup-python@v5) pinned only to mutable version tags instead of an immutable commit SHA, which creates a supply-chain risk if an action release is compromised or retagged. release.yml [15-57] Referred Code - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.11' cache: 'pip' - name: Install dependencies run: | python -m pip install --upgrade pip pip install build twine - name: Build package run: python -m build - name: Extract release notes id: extract_notes run: | ... (clipped 22 lines)
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
🔴	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Missing version validation: The release script derives the version via grep/sed without validating it is non-empty and semver-shaped, which can lead to creating/pushing an invalid tag (e.g., v) with unclear failure context. Referred Code # Get version from pyproject.toml get_current_version() { grep -E '^version = ' pyproject.toml | sed -E 's/version = "(.*)"/\1/' } # Check if tag already exists check_tag_exists() { local tag=$1 if git rev-parse "$tag" >/dev/null 2>&1; then return 0 else return 1 fi } # Main release function create_release() { local version=$(get_current_version) local tag="v$version" print_info "Current version in pyproject.toml: $version" ... (clipped 8 lines) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Unvalidated external inputs: The workflow uses the tag-derived VERSION to extract notes from CHANGELOG.md without validating the tag/version format or ensuring a matching changelog section exists, allowing malformed tags to produce incorrect/empty release notes. Referred Code VERSION=${GITHUB_REF#refs/tags/v} echo "version=$VERSION" >> $GITHUB_OUTPUT # Extract release notes from CHANGELOG.md awk -v ver="$VERSION" ' /^## \['"$VERSION"'\]/ { flag=1; next } /^## \[/ { if (flag) exit } flag { print } ' CHANGELOG.md > release_notes.md Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Secret-like example value: The release template includes an KNOWGRAPH_API_KEY example resembling a real secret (sk-...), which may encourage copying real credentials into release notes/config snippets without safeguards. Referred Code "args": ["serve"], "env": { "KNOWGRAPH_API_BASE_URL": "https://openrouter.ai/api/v1", "KNOWGRAPH_LLM_MODEL": "x-ai/grok-4.1-fast", "KNOWGRAPH_API_KEY": "sk-your-api-key-here" } } Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Consolidate the excessive and redundant documentation The PR adds four separate, overlapping documentation files for the release process. To avoid duplication and maintenance issues, consolidate all essential information into a single RELEASE.md file and move temporary, one-off instructions into the PR description. Examples: RELEASE.md [1-188] # Release Process This document describes the release process for KnowGraph. ## Overview KnowGraph follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html) and uses GitHub Actions for automated releases. ## Release Workflow ... (clipped 178 lines) HOW_TO_RELEASE.md [1-213] # 🚀 How to Create the v1.0.0 Release ## TL;DR (Too Long; Didn't Read) Once this PR is merged to main, run: ```bash git checkout main git pull ./scripts/release.sh ... (clipped 203 lines) Solution Walkthrough: Before: // Before: Multiple redundant documentation files exist. // File: RELEASE.md // - General release process... // - Troubleshooting... // File: HOW_TO_RELEASE.md // - Specific steps for v1.0.0... // - Troubleshooting... // - What the automation does... // File: RELEASE_v1.0.0.md // - Quick guide for v1.0.0... // - Troubleshooting... // File: .github/RELEASE_INFRASTRUCTURE.md // - Summary of files added in this PR... After: // After: A single, consolidated documentation file. // File: RELEASE.md // - Comprehensive release process (single source of truth). // - Versioning, changelog format. // - Troubleshooting. // - Manual fallback steps. // (Other files like HOW_TO_RELEASE.md, RELEASE_v1.0.0.md, // and .github/RELEASE_INFRASTRUCTURE.md are removed. // Temporary info is moved to the PR description.) Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies significant redundancy across multiple new documentation files, which would create a maintenance burden and confusion; consolidating them is a crucial improvement for the project's long-term health.	High
General	Improve version extraction from pyproject.toml Improve the version extraction logic in scripts/release.sh by using a more robust regular expression with grep that handles variations in spacing and quoting in pyproject.toml. scripts/release.sh [90-93] # Get version from pyproject.toml get_current_version() { - grep -E '^version = ' pyproject.toml | sed -E 's/version = "(.*)"/\1/' + grep -oP "^version\s*=\s*['\"]\K[^'\"]+" pyproject.toml } Apply / Chat Suggestion importance[1-10]: 7 __ Why: This is a valuable suggestion that improves the robustness of the release.sh script. The proposed grep -oP command is more flexible and less likely to break due to minor formatting changes in pyproject.toml.	Medium
	Detect untracked files too In scripts/release.sh, replace git diff-index with git status --porcelain to ensure the working directory is truly clean by also detecting untracked files before proceeding with a release. scripts/release.sh [75-81] check_clean() { - if ! git diff-index --quiet HEAD --; then - print_error "Working directory is not clean. Please commit or stash changes." + if [ -n "$(git status --porcelain)" ]; then + print_error "Working directory is not clean (uncommitted or untracked files exist). Please commit or stash changes." exit 1 fi print_success "Working directory is clean" } Apply / Chat Suggestion importance[1-10]: 6 __ Why: The suggestion correctly points out that git diff-index only checks for modified tracked files. Using git status --porcelain is a more robust way to ensure the working directory is completely clean by also checking for untracked files.	Low
	Update GitHub action to latest version Update the softprops/action-gh-release action from v1 to v2 and pass the GITHUB_TOKEN using with.token instead of env to align with the action's latest usage recommendations. .github/workflows/release.yml [46-56] - name: Create GitHub Release - uses: softprops/action-gh-release@v1 + uses: softprops/action-gh-release@v2 with: + token: ${{ secrets.GITHUB_TOKEN }} body_path: release_notes.md files: | dist/*.whl dist/*.tar.gz draft: false prerelease: false - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} Apply / Chat Suggestion importance[1-10]: 5 __ Why: The suggestion correctly recommends updating the softprops/action-gh-release action to v2 and passing the GITHUB_TOKEN via with.token, which aligns with current best practices and improves maintainability.	Low
Possible issue	Use exact string matching for changelog Modify the awk command in the release workflow to use exact string matching (index()) instead of a regular expression to prevent incorrect changelog section matching due to special characters like dots in version numbers. .github/workflows/release.yml [33-44] - name: Extract release notes id: extract_notes run: | VERSION=${GITHUB_REF#refs/tags/v} echo "version=$VERSION" >> $GITHUB_OUTPUT # Extract release notes from CHANGELOG.md - awk -v ver="$VERSION" ' - /^## \['"$VERSION"'\]/ { flag=1; next } + awk -v ver="## [$VERSION]" ' + index($0, ver) == 1 { flag=1; next } /^## \[/ { if (flag) exit } flag { print } ' CHANGELOG.md > release_notes.md Apply / Chat Suggestion importance[1-10]: 6 __ Why: This is a valid suggestion that correctly identifies a potential bug where a dot in the version string would be treated as a wildcard in the awk regex, leading to incorrect matches. The proposed fix using index() is more robust.	Low
More