Skip to content

Release Collector: Consolidate meta-release viewers into single parameterized viewer #100

Description

@hdamker

Problem description

The Release Collector currently generates separate HTML viewer files for each meta-release (fall24.html, spring25.html, fall25.html). This creates maintenance overhead:

  1. The REQUIRED_FILES array in release-collector-production.yml must be manually updated when adding new meta-releases
  2. Multiple nearly-identical HTML files to maintain
  3. Wiki embedding requires different URLs for each meta-release

Possible evolution

Replace the dedicated meta-release viewers with a single parameterized viewer that accepts the meta-release as a URL parameter:

  • Single file: viewers/meta-release.html
  • URL parameter: ?meta-release=Spring25
  • Filter logic applied on page load based on parameter
  • Validate parameter against known meta-releases from embedded config
  • Show selector or error message if parameter missing/invalid

Benefits:

  • Fixed set of deployment files (meta-release.html + portfolio.html)
  • No workflow updates needed when adding new meta-releases
  • Single codebase to maintain and enhance
  • meta-release-mappings.yaml becomes single source of truth

Alternative solution

Derive REQUIRED_FILES dynamically from config/meta-release-mappings.yaml during validation. This keeps separate files but removes manual updates. Less elegant but lower implementation effort.

Additional context

Related to PR #98 review comment about hardcoded REQUIRED_FILES. The parameterized viewer approach aligns with the goal of reducing per-meta-release maintenance tasks.

Metadata

Metadata

Assignees

No one assigned

    Labels

    backlogPostponed issue for later considerationenhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions