Update GitHub Actions workflows: use ubuntu-24.04 and pin actions with commit SHAs

[simonrey1]

Description

The GitHub Actions workflows should be updated to:

1. Use ubuntu-24.04 runner: Update all jobs from ubuntu-22.04 to ubuntu-24.04 to use the latest LTS Ubuntu runner.

2. Pin actions with commit SHAs: Replace all action version tags with commit SHAs for better security and reproducibility. Include version comments after each SHA for maintainability.

Changes needed

For all workflow files (e.g., build-publish.yaml, release.yaml):

Update runners:

runs-on: ubuntu-24.04  # was: ubuntu-22.04

Pin actions with SHAs (examples):

- uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4
- uses: redhat-actions/buildah-build@7a95fa7ee0f02d552a32753e7414641a04307056 # v2
- uses: redhat-actions/podman-login@4934294ad0449894bcd1e9f191899d7292469603 # v1
- uses: redhat-actions/push-to-registry@5ed88d269cf581ea9ef6dd6806d01562096bee9c # v2

Benefits

• Security: Pinning to exact commits prevents supply chain attacks through tag manipulation
• Reproducibility: Ensures consistent behavior across workflow runs
• Maintainability: Version comments make it easy to see which version each SHA corresponds to
• Up-to-date runner: Ubuntu 24.04 provides the latest LTS features and security updates

Reference

These changes have been implemented in the extension-pack-kubernetes repository and can serve as a reference.

[simonrey1]

Additional Task: Document Workflows in README

The README.md should also be updated to document the purpose and usage of the two workflows (build-publish.yaml and release.yaml).

Recommended Documentation Structure

Add a Development section to the README explaining:

build-publish.yaml - Continuous Integration

• Purpose: Automatically builds and publishes nightly versions
• Trigger: Runs on every push to main (and manual workflow_dispatch)
• Tags: nightly and commit SHA
• Use case: Continuous integration and nightly builds for testing

release.yaml - Official Releases

• Purpose: Creates official versioned releases
• Trigger: Manual only via workflow_dispatch
• Inputs: version (e.g., 1.0.0) and branch (default: main)
• Process: Updates package.json → creates git tag → builds image → creates GitHub release
• Tags: latest and version number
• Use case: Official releases for end users

Which Workflow to Use?

• build-publish.yaml: Runs automatically, no intervention needed
• release.yaml: Use when ready to create an official versioned release (manual trigger required)

See the extension-pack-kubernetes repository README for a complete example.