docs-v2/helper-scripts/common
Jason Stirnaman 9a4721aa40 chore(ci): Automation scripts to compare influxdb3 CLI help to reference documentation and generate an audit report, runs influxdb3 core and enterprise using Docker, improves compose.yaml, restructures helper-scripts for different versions 2025-07-07 12:13:36 -05:00
..
lib chore(ci): Automation scripts to compare influxdb3 CLI help to reference documentation and generate an audit report, runs influxdb3 core and enterprise using Docker, improves compose.yaml, restructures helper-scripts for different versions 2025-07-07 12:13:36 -05:00
README.md chore(ci): Automation scripts to compare influxdb3 CLI help to reference documentation and generate an audit report, runs influxdb3 core and enterprise using Docker, improves compose.yaml, restructures helper-scripts for different versions 2025-07-07 12:13:36 -05:00
generate-release-notes.sh chore(ci): Automation scripts to compare influxdb3 CLI help to reference documentation and generate an audit report, runs influxdb3 core and enterprise using Docker, improves compose.yaml, restructures helper-scripts for different versions 2025-07-07 12:13:36 -05:00
update-product-version.sh chore(ci): Automation scripts to compare influxdb3 CLI help to reference documentation and generate an audit report, runs influxdb3 core and enterprise using Docker, improves compose.yaml, restructures helper-scripts for different versions 2025-07-07 12:13:36 -05:00

README.md

Common Helper Scripts

This directory contains scripts that are shared across all InfluxDB documentation products.

Scripts

generate-release-notes.sh

Generates release notes by analyzing git commits between two versions across multiple repositories.

Usage:

./generate-release-notes.sh [options] <from_version> <to_version> <primary_repo> [additional_repos...]

Options:

  • --no-fetch - Skip fetching latest commits from remote
  • --pull - Pull latest changes (use with caution)

Example:

# Generate release notes for v3.2.0
./generate-release-notes.sh v3.1.0 v3.2.0 ~/repos/influxdb ~/repos/influxdb_iox

# Skip fetch for faster local testing
./generate-release-notes.sh --no-fetch v3.1.0 v3.2.0 ~/repos/influxdb

Output:

  • Creates release-notes-<version>.md in current directory
  • Includes sections for Features, Bug Fixes, Breaking Changes, Performance, and API changes

update-product-version.sh

Updates product version information in documentation configuration files.

Usage:

./update-product-version.sh --product <product> --version <version>

Supported Products:

  • core - InfluxDB 3 Core
  • enterprise - InfluxDB 3 Enterprise
  • clustered - InfluxDB 3 Clustered
  • cloud-dedicated - InfluxDB 3 Cloud Dedicated
  • cloud-serverless - InfluxDB Cloud Serverless

Example:

# Update Core to version 3.2.1
./update-product-version.sh --product core --version 3.2.1

# Update Clustered to version 2024.1
./update-product-version.sh --product clustered --version 2024.1

What it updates:

  • data/products.yml - Main product version configuration
  • Docker Compose example files
  • Installation instructions
  • Download links

Library Functions

lib/docker-utils.sh

Shared Docker utility functions used by other scripts.

Available Functions:

  • check_docker_running() - Verify Docker daemon is running
  • container_exists() - Check if a container exists
  • container_running() - Check if a container is running
  • pull_image() - Pull Docker image with retry logic
  • load_auth_token() - Load authentication tokens from secret files

Usage in scripts:

source "$(dirname "$0")/../common/lib/docker-utils.sh"

if container_running "influxdb3-core"; then
    echo "Container is running"
fi

Integration with GitHub Actions

These scripts are designed to work in both local development and CI/CD environments:

Local Development:

  • Assumes Docker Desktop or Docker Engine installed
  • Uses local file paths for repositories
  • Can work with running containers

GitHub Actions:

  • Automatically detects CI environment
  • Uses workspace paths
  • Handles authentication via secrets

Best Practices

  1. Error Handling: All scripts use set -e to exit on errors
  2. Logging: Color-coded output for better readability
  3. Validation: Input validation before processing
  4. Idempotency: Scripts can be run multiple times safely
  5. Documentation: Comprehensive help text in each script

Adding New Common Scripts

When adding scripts to this directory:

  1. Ensure they are truly product-agnostic
  2. Follow existing naming conventions
  3. Add comprehensive documentation
  4. Include error handling and validation
  5. Update this README
  6. Test with all supported products