odh-trigger-release

name	odh-trigger-release
description	Intelligently trigger ODH releases with component readiness preview and fallback guidance
user_invocable	true

ODH Trigger Release Skill

Purpose

Guide release managers through triggering ODH releases with intelligent component readiness assessment and fallback preview. This skill leverages existing component mapping logic to show exactly what will be included in the release and helps make informed decisions about proceeding with fallbacks or waiting for missing registrations.

Usage

• /odh-trigger-release - Check release readiness and trigger current release
• /odh-trigger-release <version> - Trigger specific release version

Conversational Flow

1. Release Identification & Status Check

• Auto-detect current active release or ask for version
• Show release status, timeline, and registration deadline context
• Validate release is in appropriate state for triggering

2. Component Readiness Assessment

• Use existing check_release_readiness.sh for component status
• Parse build_component_mapping.sh for fallback preview
• Show registered vs fallback vs missing components with clear categorization

3. Fallback Intelligence Display

• Show detailed fallback information for unregistered components
• Explain which previous release versions will be used
• Provide context about fallback component versions and their stability

4. Decision Guidance

• Present clear options based on readiness assessment
• Guide decision making with component team notification suggestions
• Show impact of proceeding vs waiting

5. Execution with Monitoring Setup

• Trigger existing workflow with gathered information
• Provide external staging monitoring links
• Set up tracking for release progression

Integration Points

Existing ODH Infrastructure

• Readiness Check: Uses existing .github/scripts/check_release_readiness.sh
• Component Mapping: Leverages .github/scripts/build_component_mapping.sh fallback logic
• Release Status: Reads current release from configs/release-status.yaml
• Workflow: Triggers existing trigger-release.yaml GitHub Actions workflow
• Monitoring: Tracks external workflow URLs for staging progress

Preserves Existing Process

• Same trigger workflow and inputs
• Identical fallback logic and component resolution
• No changes to existing release mechanics
• Maintains audit trail and external integration

Example Interaction

User: /odh-trigger-release

Claude: I'll check release readiness and help trigger the release.

Current Release: v3.5.0
   - Status: scheduled (ready for triggering)
   - Release Date: 2026-07-15
   - Days until release: 12

Checking component registration status...

Component Readiness Assessment:

Registered (15/19):
   • dashboard v2.8.0 (release-v2.8 branch)
   • workbenches/notebooks v1.9.0 (main branch)  
   • model-serving v2.1.0 (release-v2.1 branch)
   • kserve v1.8.0 (main branch)
   ... 11 more

Will use fallback (4/19):
   • ray → v2.0.0 from v3.4.0 release
   • trustyai → v1.2.0 from v3.4.0 release  
   • authorino → v0.8.0 from v3.4.0 release
   • codeflare → v1.5.0 from v3.4.0 release

No previous versions (0/19): None

15/19 components ready (79%). Proceed with fallbacks for missing components?

   Hint: Fallbacks use stable versions from previous release (v3.4.0)
   You can register missing components first, or proceed with fallbacks

   Options:
   1. Proceed with fallbacks (trigger release now)
   2. Wait for missing registrations  
   3. Show detailed fallback information first
   4. Notify component teams about missing registrations

User: 3

Detailed Fallback Information:

ray (Ray Cluster):
   - Will use: v2.0.0 from v3.4.0 release
   - Age: 2 months old
   - Status: Stable, last known working version
   - Team: @ray-team (GitHub: ray-project/kuberay-operator)

trustyai (TrustyAI):  
   - Will use: v1.2.0 from v3.4.0 release
   - Age: 2 months old
   - Status: Stable, includes security fixes
   - Team: @trustyai-team (GitHub: trustyai-explainability/trustyai-service-operator)

authorino (Authorino):
   - Will use: v0.8.0 from v3.4.0 release  
   - Age: 2 months old
   - Status: Stable, compatible with current ODH
   - Team: @authorino-team (GitHub: kuadrant/authorino-operator)

codeflare (CodeFlare):
   - Will use: v1.5.0 from v3.4.0 release
   - Age: 2 months old  
   - Status: Stable, core functionality maintained
   - Team: @codeflare-team (GitHub: project-codeflare/codeflare-operator)

All fallback versions are stable and tested. Trigger release with these fallbacks?

   Options:
   1. Yes, trigger release with fallbacks
   2. No, wait for team registrations
   3. Notify teams first, then decide

User: 1

Triggering v3.5.0 release...
   • 15 registered components
   • 4 fallback components  
   • 0 missing components

Release triggered successfully!
   
Monitoring Information:
   • External staging: https://github.com/opendatahub-io/opendatahub-operator/actions/runs/12345
   • Release tracking: Updated configs/release-status.yaml
   • Status: awaiting_validation

Next steps:
1. Monitor external staging progress (~30-45 minutes)
2. QE validation when staging completes  
3. Community release trigger after validation approval

Use /odh-monitor-community to track progress automatically.

Error Handling & Guidance

No Active Release

• Clear explanation of release status and timing
• Guidance on using /odh-set-next-release to plan releases
• Links to release documentation and process

Release Not Ready for Triggering

• Explain current release status and what's needed
• Show timeline and deadline context
• Guide on registration process for missing components

Component Readiness Issues

• Detailed breakdown of missing vs fallback components
• Suggestions for component team outreach
• Impact assessment of proceeding vs waiting

Workflow Execution Issues

• Clear error messages for GitHub API failures
• Fallback guidance for manual workflow execution
• Links to staging monitoring and troubleshooting

Implementation Details

Required Tools & Scripts

• Python script: .claude/skills/odh-trigger-release/scripts/trigger.py
• Readiness integration: Wrapper for existing release readiness checks
• Mapping logic: Integration with component fallback resolution
• GitHub API: Workflow triggering and external URL tracking

Dependencies

• Access to .github/scripts/check_release_readiness.sh
• Access to .github/scripts/build_component_mapping.sh
• Read/write access to configs/release-status.yaml
• GitHub API permissions for workflow triggering
• External repository monitoring capabilities

Intelligent Features

• Component categorization: Registered vs fallback vs missing
• Fallback preview: Version ages, stability assessment, team context
• Decision support: Impact analysis and recommendation guidance
• Monitoring setup: Automatic tracking of external workflows

Component Intelligence

Readiness Assessment

• Parse component registration completeness
• Categorize components by availability status
• Calculate readiness percentages for decision support

Fallback Analysis

• Use existing fallback logic from build_component_mapping.sh
• Show version ages and stability context
• Provide team contact information for missing registrations

Impact Evaluation

• Assess release quality with current component set
• Highlight critical vs optional missing components
• Guide decision making with historical context

Future Enhancements

• Automatic component team notification for missing registrations
• Integration with component health monitoring for fallback assessment
• Predictive analysis for optimal release timing
• Advanced conflict detection between component versions