docs-v2/helper-scripts/influxdb3-plugins/README.md

669 lines
21 KiB
Markdown

# InfluxDB 3 Plugin Documentation Automation
This directory contains scripts and configuration for automating plugin documentation sync between `influxdata/influxdb3_plugins` (source) and `influxdata/docs-v2` (documentation site).
## Files in This Directory
- **`port_to_docs.js`** - Transforms plugin READMEs from influxdb3_plugins to docs-v2 format
- **`docs_mapping.yaml`** - Maps source plugin READMEs to destination documentation files
- **`README.md`** - This file: complete workflow documentation
## Quick Start
### Automated Sync (Recommended)
When you update plugin READMEs in influxdb3_plugins:
1. **Commit your changes** - The reminder workflow will automatically detect changes
2. **Click the sync link** - A comment will appear with a pre-filled link to create a sync request
3. **Review the PR** - The workflow creates a pull request with transformed content and screenshots
### Manual Sync (Alternative)
To manually trigger synchronization:
1. **Create sync request**: [Open sync request form](https://github.com/influxdata/docs-v2/issues/new?template=sync-plugin-docs.yml)
2. **Fill in plugin names** and source commit
3. **Submit issue** - This automatically triggers the sync workflow
### Local Development
For local testing and development:
1. **Validate source content** (run from influxdb3_plugins directory):
```bash
cd /path/to/influxdb3_plugins
python scripts/validate_readme.py
```
2. **Transform content** (run from docs-v2 root directory):
```bash
cd /path/to/docs-v2
npm run sync-plugins
```
3. **Review changes**:
```bash
git diff content/shared/influxdb3-plugins/
```
## NPM Scripts
From the docs-v2 root directory, you can use these convenient npm scripts:
- `npm run sync-plugins` - Transform all plugin documentation
- `npm run sync-plugins:dry-run` - Preview changes without writing files
- `npm run validate-plugin-config` - Validate the mapping configuration
## Overview
This workflow maintains consistent plugin documentation between repositories while ensuring bidirectional consistency and enabling future automation.
## Key Principles
1. **Single Source of Truth**: Plugin READMEs in `influxdb3_plugins` are the canonical source
2. **Consistency**: All plugin READMEs follow a standardized template
3. **Automation**: Documentation updates flow automatically from source to docs
4. **Validation**: Both repositories validate documentation quality
5. **No Divergence**: Content differences are managed through transformation rules
## Repository Responsibilities
### influxdb3_plugins (Source)
- Contains canonical plugin documentation in README files
- Follows strict template structure
- Includes all technical details and examples
- Validates README compliance
### docs-v2 (Documentation Site)
- Transforms and enhances source documentation
- Adds product-specific formatting and shortcodes
- Includes additional support sections
- Never directly edits plugin content
## Phase 1: Standardize Source Documentation
### 1.1 README Template Structure
All plugin READMEs in `influxdb3_plugins` must follow this structure:
```markdown
# [Plugin Name]
⚡ [trigger-type1, trigger-type2] 🏷️ [tag1, tag2, tag3] 🔧 InfluxDB 3 Core, InfluxDB 3 Enterprise
## Description
[2-4 sentences describing what the plugin does, its main capabilities, supported trigger types, and any special features]
## Configuration
Plugin parameters may be specified as key-value pairs in the `--trigger-arguments` flag (CLI) or in the `trigger_arguments` field (API) when creating a trigger. Some plugins support TOML configuration files, which can be specified using the plugin's `config_file_path` parameter.
If a plugin supports multiple trigger specifications, some parameters may depend on the trigger specification that you use.
### Plugin metadata
This plugin includes a JSON metadata schema in its docstring that defines supported trigger types and configuration parameters. This metadata enables the [InfluxDB 3 Explorer](https://docs.influxdata.com/influxdb3/explorer/) UI to display and configure the plugin.
### Required parameters
| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `param_name` | string | required | Description of parameter |
### [Category] parameters
[Additional parameter tables organized by category]
### TOML configuration
| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `config_file_path` | string | none | TOML config file path relative to `PLUGIN_DIR` (required for TOML configuration) |
*To use a TOML configuration file, set the `PLUGIN_DIR` environment variable and specify the `config_file_path` in the trigger arguments.* This is in addition to the `--plugin-dir` flag when starting InfluxDB 3.
#### Example TOML configurations
- [config_file.toml](config_file.toml) - Description
For more information on using TOML configuration files, see the Using TOML Configuration Files section in the [influxdb3_plugins/README.md](/README.md).
## [Special Requirements Section - if applicable]
[For example: Data requirements, Schema requirements, Software requirements]
## Installation steps
1. Start InfluxDB 3 with the Processing Engine enabled:
```bash
influxdb3 serve \
--node-id node0 \
--object-store file \
--data-dir ~/.influxdb3 \
--plugin-dir ~/.plugins
```
2. Install required Python packages (if any):
```bash
influxdb3 install package package_name
```
## Trigger setup
### [Trigger Type 1]
[Description and example]
```bash
influxdb3 create trigger \
--database mydb \
--plugin-filename gh:influxdata/[plugin]/[plugin].py \
--trigger-spec "[spec]" \
--trigger-arguments '[arguments]' \
trigger_name
```
### [Trigger Type 2]
[Additional trigger examples as needed]
## Example usage
### Example 1: [Use case name]
[Description of the example]
```bash
# Create the trigger
influxdb3 create trigger \
--database mydb \
--plugin-filename gh:influxdata/[plugin]/[plugin].py \
--trigger-spec "[spec]" \
--trigger-arguments '[arguments]' \
trigger_name
# Write test data
influxdb3 write \
--database mydb \
"measurement,tag=value field=1"
# Query results
influxdb3 query \
--database mydb \
"SELECT * FROM result_measurement"
```
### Expected output
```
[Expected output format]
```
**Details:**
- Before: [input state]
- After: [output state]
### Example 2: [Use case name]
[Additional examples following the same pattern]
## Code overview
### Files
- `plugin_name.py`: Main plugin code
- `config.toml`: Example configuration file
### Main functions
#### `function_name(params)`
[Description of what the function does]
Key operations:
1. [Operation 1]
2. [Operation 2]
3. [Operation 3]
### Key logic
[Description of the plugin's core logic and processing flow]
## Troubleshooting
### Common issues
#### Issue: [Problem description]
**Solution**: [How to fix it]
#### Issue: [Problem description]
**Solution**: [How to fix it]
### Debugging tips
1. **[Tip 1]**: [Description]
2. **[Tip 2]**: [Description]
### Performance considerations
- [Performance note 1]
- [Performance note 2]
## Questions/Comments
For questions or comments about this plugin, please open an issue in the [influxdb3_plugins repository](https://github.com/influxdata/influxdb3_plugins/issues).
```
### 1.2 Validation Requirements
Each README must:
- Include all required sections in the correct order
- Use consistent parameter table formatting
- Provide at least 2 complete usage examples
- Include expected output for examples
- Document all configuration parameters
- Link to TOML configuration files (if applicable)
## Phase 2: Transformation to docs-v2
### 2.1 Transformation Rules
When porting content from `influxdb3_plugins` to `docs-v2`:
#### Content Transformations
1. **Remove emoji metadata line** (already in plugin metadata)
2. **Convert relative links to GitHub URLs**:
- `[file.toml](file.toml)` → `[file.toml](https://github.com/influxdata/influxdb3_plugins/blob/master/influxdata/[plugin]/file.toml)`
- `/README.md` → `https://github.com/influxdata/influxdb3_plugins/blob/master/README.md`
3. **Add product shortcodes**:
- Replace "InfluxDB 3" with `{{% product-name %}}`
- Add `{{% token-link %}}` for token references
- Use `{{% show-in "enterprise" %}}` for conditional content
4. **Enhance opening paragraph** (optional):
- Can be expanded for better SEO and context
- Must maintain factual accuracy
5. **Add docs-specific sections**:
```markdown
## Logging
Logs are stored in the `_internal` database (or the database where the trigger is created) in the `system.processing_engine_logs` table. To view logs:
```bash
influxdb3 query --database _internal "SELECT * FROM system.processing_engine_logs WHERE trigger_name = 'your_trigger_name'"
```
Log columns:
- **event_time**: Timestamp of the log event
- **trigger_name**: Name of the trigger that generated the log
- **log_level**: Severity level (INFO, WARN, ERROR)
- **log_text**: Message describing the action or error
## Report an issue
For plugin issues, see the Plugins repository [issues page](https://github.com/influxdata/influxdb3_plugins/issues).
## Find support for {{% product-name %}}
The [InfluxDB Discord server](https://discord.gg/9zaNCW2PRT) is the best place to find support for InfluxDB 3 Core and InfluxDB 3 Enterprise.
```
### 2.2 File Structure in docs-v2
Plugin documentation location:
- **Official plugins**: `/content/shared/influxdb3-plugins/plugins-library/official/[plugin-name].md`
- **Example plugins**: `/content/shared/influxdb3-plugins/plugins-library/examples/[plugin-name].md`
- **Community plugins**: `/content/shared/influxdb3-plugins/plugins-library/community/[plugin-name].md`
## Phase 3: Automation Implementation
### 3.1 Validation Script (scripts/validate_readme.py)
```python
#!/usr/bin/env python3
"""
Validates plugin README files against the standard template.
"""
import sys
import re
from pathlib import Path
REQUIRED_SECTIONS = [
"# ", # Title
"## Description",
"## Configuration",
"### Required parameters",
"## Installation steps",
"## Trigger setup",
"## Example usage",
"## Code overview",
"## Troubleshooting",
"## Questions/Comments"
]
def validate_readme(readme_path):
"""Validate a README file against the template."""
with open(readme_path, 'r') as f:
content = f.read()
errors = []
# Check for required sections
for section in REQUIRED_SECTIONS:
if section not in content:
errors.append(f"Missing required section: {section}")
# Check for emoji metadata
if not re.search(r'^⚡.*🏷️.*🔧', content, re.MULTILINE):
errors.append("Missing emoji metadata line")
# Check for parameter tables
if '| Parameter |' not in content:
errors.append("No parameter tables found")
# Check for code examples
if '```bash' not in content:
errors.append("No bash code examples found")
# Check for expected output
if '### Expected output' not in content and '**Expected output' not in content:
errors.append("No expected output section found")
return errors
if __name__ == "__main__":
# Validate all plugin READMEs
plugin_dirs = Path('influxdata').glob('*/README.md')
all_valid = True
for readme_path in plugin_dirs:
errors = validate_readme(readme_path)
if errors:
all_valid = False
print(f"\n❌ {readme_path}:")
for error in errors:
print(f" - {error}")
else:
print(f"✅ {readme_path}")
sys.exit(0 if all_valid else 1)
```
### 3.2 Transformation Script (port_to_docs.py)
```python
#!/usr/bin/env python3
"""
Transforms plugin READMEs from influxdb3_plugins to docs-v2 format.
"""
import re
import yaml
from pathlib import Path
def transform_content(content, plugin_name):
"""Transform README content for docs-v2."""
# Remove emoji metadata line
content = re.sub(r'^⚡.*🔧.*$', '', content, flags=re.MULTILINE)
# Convert relative links to GitHub URLs
base_url = f"https://github.com/influxdata/influxdb3_plugins/blob/master/influxdata/{plugin_name}/"
content = re.sub(r'\[([^\]]+)\]\(([^)]+\.toml)\)',
f'[\\1]({base_url}\\2)', content)
# Replace InfluxDB 3 references
content = content.replace('InfluxDB 3 Core/Enterprise', '{{% product-name %}}')
content = content.replace('InfluxDB 3', '{{% product-name %}}')
# Remove Questions/Comments section (will be replaced)
content = re.sub(r'## Questions/Comments.*', '', content, flags=re.DOTALL)
# Add docs-specific sections
docs_sections = """
## Logging
Logs are stored in the `_internal` database (or the database where the trigger is created) in the `system.processing_engine_logs` table. To view logs:
```bash
influxdb3 query --database _internal "SELECT * FROM system.processing_engine_logs WHERE trigger_name = 'your_trigger_name'"
```
Log columns:
- **event_time**: Timestamp of the log event
- **trigger_name**: Name of the trigger that generated the log
- **log_level**: Severity level (INFO, WARN, ERROR)
- **log_text**: Message describing the action or error
## Report an issue
For plugin issues, see the Plugins repository [issues page](https://github.com/influxdata/influxdb3_plugins/issues).
## Find support for {{% product-name %}}
The [InfluxDB Discord server](https://discord.gg/9zaNCW2PRT) is the best place to find support for InfluxDB 3 Core and InfluxDB 3 Enterprise.
"""
return content + docs_sections
def process_plugin(source_path, target_path, plugin_name):
"""Process a single plugin README."""
with open(source_path, 'r') as f:
content = f.read()
transformed = transform_content(content, plugin_name)
# Ensure target directory exists
target_path.parent.mkdir(parents=True, exist_ok=True)
with open(target_path, 'w') as f:
f.write(transformed)
print(f"✅ Processed {plugin_name}")
if __name__ == "__main__":
# Load mapping configuration
with open('docs_mapping.yaml', 'r') as f:
config = yaml.safe_load(f)
for plugin_name, mapping in config['plugins'].items():
source = Path(mapping['source'])
target = Path(mapping['target'])
if source.exists():
process_plugin(source, target, plugin_name)
else:
print(f"❌ Source not found: {source}")
```
### 3.3 Mapping Configuration (docs_mapping.yaml)
```yaml
plugins:
basic_transformation:
source: influxdata/basic_transformation/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/basic-transformation.md
category: official
downsampler:
source: influxdata/downsampler/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/downsampler.md
category: official
forecast_error_evaluator:
source: influxdata/forecast_error_evaluator/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/forecast-error-evaluator.md
category: official
influxdb_to_iceberg:
source: influxdata/influxdb_to_iceberg/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/influxdb-to-iceberg.md
category: official
mad_check:
source: influxdata/mad_check/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/mad-check.md
category: official
notifier:
source: influxdata/notifier/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/notifier.md
category: official
prophet_forecasting:
source: influxdata/prophet_forecasting/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/prophet-forecasting.md
category: official
state_change:
source: influxdata/state_change/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/state-change.md
category: official
stateless_adtk_detector:
source: influxdata/stateless_adtk_detector/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/stateless-adtk-detector.md
category: official
system_metrics:
source: influxdata/system_metrics/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/system-metrics.md
category: official
threshold_deadman_checks:
source: influxdata/threshold_deadman_checks/README.md
target: ../docs-v2/content/shared/influxdb3-plugins/plugins-library/official/threshold-deadman-checks.md
category: official
```
## Phase 4: GitHub Actions Automation
### 4.1 Automated Workflow Architecture
The plugin documentation sync process uses a two-repository workflow:
1. **influxdb3_plugins**: Detects README changes and creates reminder comments
2. **docs-v2**: Handles the complete sync workflow via issue-triggered automation
### 4.2 Reminder System (influxdb3_plugins)
**File**: `.github/workflows/remind-sync-docs.yml`
- **Triggers**: On pushes to `influxdata/**/README.md` files
- **Action**: Creates commit comment with pre-filled link to docs-v2 sync form
- **No secrets required**: Pure URL-based integration
**Flow**:
```
Plugin README change → Commit → Automatic comment with sync link
```
### 4.3 Sync Automation (docs-v2)
**Files**:
- `.github/workflows/sync-plugins.yml` - Main sync workflow
- `.github/ISSUE_TEMPLATE/sync-plugin-docs.yml` - Issue template for requests
**Triggers**:
- Issue creation with `sync-plugin-docs` label (from template)
- Manual workflow dispatch
**Process**:
1. **Parse request** - Extract plugin names and source commit from issue
2. **Validate source** - Run `scripts/validate_readme.py` on specified plugins
3. **Transform content** - Apply docs-v2 formatting and enhancements
4. **Generate screenshots** - Capture Hugo-rendered plugin pages
5. **Create PR** - Submit changes with comprehensive summary
6. **Update issue** - Close with success/failure status
### 4.4 Key Features
- **No cross-repo secrets** - Uses URL parameters and public APIs
- **Visual validation** - Screenshots included in PRs
- **Comprehensive error handling** - Clear feedback on failures
- **Selective sync** - Individual plugins or "all"
- **Progress tracking** - Issue updates throughout process
## Phase 5: Manual Workflow (Until Automation is Ready)
### Step 1: Update Source README
1. Edit README in `influxdb3_plugins/influxdata/[plugin]/`
2. Run validation: `python scripts/validate_readme.py`
3. Fix any validation errors
### Step 2: Transform Content
1. Change to docs-v2 directory: `cd ../docs-v2`
2. Run transformation: `npm run sync-plugins`
3. Review generated content: `git diff content/shared/influxdb3-plugins/`
### Step 3: Manual Adjustments (if needed)
1. Add any docs-specific enhancements
2. Verify shortcodes and formatting
3. Test links and examples
### Step 4: Commit and PR
1. Commit changes in influxdb3_plugins
2. Commit transformed content in docs-v2
3. Reference source commit in docs-v2 commit message
## Maintenance Guidelines
### For New Plugins
1. Create README following template in `influxdb3_plugins`
2. Add entry to `docs_mapping.yaml`
3. Run validation and transformation scripts
4. Review and merge generated documentation
### For Updates
1. Update source README in `influxdb3_plugins`
2. Automation (or manual script) creates PR to docs-v2
3. Review for accuracy and merge
### Exception Handling
- Use `[no-sync]` in commit message to skip automation
- Document special cases in `exceptions.yaml`
- Manual override allowed for urgent fixes
## Quality Assurance Checklist
Before merging any plugin documentation:
- [ ] Source README passes validation (`scripts/validate_readme.py`)
- [ ] All required sections present and properly formatted
- [ ] At least 2 complete usage examples with expected output
- [ ] All configuration parameters documented
- [ ] Links to GitHub source files work
- [ ] TOML configuration documented (if applicable)
- [ ] Transformation script runs without errors
- [ ] Generated docs-v2 content is accurate
- [ ] Product shortcodes properly applied
- [ ] Support sections included
## Benefits of This Workflow
1. **Consistency**: Single source of truth eliminates divergence
2. **Automation**: Reduces manual work and human error
3. **Validation**: Ensures quality standards are met
4. **Scalability**: Easy to add new plugins
5. **Maintainability**: Clear ownership and update process
6. **Traceability**: Git history shows relationship between repos
## Future Enhancements
1. **Automated testing** of code examples
2. **Version tracking** for plugin compatibility
3. **Changelog generation** from commit history
4. **Multi-language** example generation
5. **API documentation** generation from metadata
6. **Search optimization** through automated tagging
## Conclusion
This workflow establishes a sustainable process for maintaining high-quality, consistent plugin documentation across both repositories while enabling progressive automation. The standardized template and transformation rules ensure that documentation remains synchronized while allowing for repository-specific requirements.