Description

We require a Github action to create release candidates for existing release branches. GitHub's standard "pre-release" should be used for the release. The action should allow to trigger the process for one or multiple components. The created tags will be immutable (repository setting). In case of failures for any component where the release tag has already been created, a new valid rc name for that component needs to be specified.

Action Input:

• release branch name (releases/vX.Z) --> is offered by default in GitHub as drop-down with text "Use workflow from"
• list of all existing components with field to enter RC name (rc.X)

on:
  workflow_dispatch:
    inputs:
      cli_rc_name:
        description: 'CLI RC name (e.g. rc.1, rc.2) - leave empty to skip'
        required: false
        type: string
      controller_rc_name:
        description: 'Controller RC name (e.g. rc.1, rc.2) - leave empty to skip'
        required: false
        type: string

Components (so far, website potentially coming soon)

cli → Tag format: cli/vX.Y.0-rc.N
kubernetes/controller → Tag format: kubernetes/controller/vX.Y.0-rc.N

Tasks:

1. Input Validation

• Validate that at least one component RC name is provided
• Validate RC name format matches rc.[0-9]+ (e.g. rc.1, rc.2)
• Validate branch name matches pattern releases/v[0-9]+.[0-9]+
• Extract version from branch name (e.g. releases/v0.9 → v0.9.0)
• Check if git tags already exist for the specified components and RC names
• Skip components where tags already exist (log warning) instead of aborting
• Abort workflow only if: invalid format, invalid branch name, or ALL specified components already have tags

2. Git Tag Creation

• Create git tags for each specified component with format /vX.Y.0-rc.N
• Tags should be immutable
• Push tags to repository

3. Build Process

• Set up parallel build jobs for each component (if multiple components are specified)
• Build CLI component (if cli_rc_name provided)
• Build kubernetes/controller component (if controller_rc_name provided)
• Generate build artifacts/binaries and potentially OCI image(s) for each component

4. GitHub (Pre-)Release Creation

• Create separate GitHub pre-release for each component
• Release title format: vX.Y.0-rc.N
• Generate and include release notes for each component
• Attach build artifacts/assets to respective releases
• Mark releases as pre-release

5. Error Handling

• Ensure workflow aborts if input validation fails (format errors, branch errors)
• If a component fails after tag creation, workflow continues for other components but marks run as failed
• Failed components can be retried in a subsequent workflow run with the same RC name (only if tag has not already been created, tags are immutable)
• Provide clear error messages for each failure scenario

6. Summary Output

• Display summary of created release candidates in workflow run summary
• Show branch, version, and created tags

Optional (if there's time and to record for future tasks)

• Create build attestations using https://github.com/actions/attest-build-provenance. Those can be picked up in the promote workflow to verify integrity before promotion.

Done Criteria

• Workflow created as Github action
• Workflow can be triggered manually from GitHub UI with specified input
• Components are built in parallel when multiple are specified
• Each component gets its own GitHub pre-release with artifacts and release notes
• Code has been reviewed by other team members
• Internal technical Documentation created/updated (if applicable)
• Successful demonstration in Review