[jaeger] Add weekly workflow to auto-update Jaeger version from Docker Hub

[Copilot]

What this PR does

Adds a new GitHub Actions workflow (.github/workflows/update-jaeger-version.yaml) and standalone script (.github/scripts/update-jaeger-version.sh) that automatically checks for new Jaeger releases on Docker Hub and creates PRs to update the chart.

Workflow behavior:

• Runs weekly (Monday 00:00 UTC) or on-demand via workflow_dispatch
• Checks jaegertracing/jaeger:latest digest against semantic version tags
• Compares with current appVersion in charts/jaeger/Chart.yaml
• If newer version exists:
  • Updates appVersion to new version
  • Bumps chart version minor (e.g., 4.0.0 → 4.1.0)
  • Creates PR using jaegertracingbot account

Manual trigger options:

• dry_run parameter: prints what changes would be made without creating PR

Implementation details:

• Standalone script in .github/scripts/update-jaeger-version.sh can be tested individually
• Uses sed for YAML manipulation (no external dependencies like yq)
• Handles multi-platform image digests
• Validates semver format before parsing
• Handles dry_run parameter absence when running from cron (defaults to false)
• Explicit permissions: contents: read for security
• Error handling for Docker Hub API calls

Which issue this PR fixes

(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format,
will close that issue when PR gets merged)

• fixes #

Checklist

• DCO signed
• Commits are GPG signed
• Chart Version bumped
• Title of the PR starts with chart name ([jaeger] or [jaeger-operator])
• README.md has been updated to match version/contain new values

Original prompt

I want to create a new workflow that executes once a week, but can also be triggered manually (in which case it should accept a dry_run argument). It's objective is to:

1. check if there is a new Docker Hub release of jaegertracing/jaeger image
2. if there is, replace the appVersion value in the charts/jaeger/Chart.yaml file
3. also bump version field in the chart to new minor version
4. create a PR with the changes using the 2nd script below as the prototype

This is the prototype script to do steps 1-2. You need to add step 3, and the dry-run capability that will skip creating the PR and only print that a change is needed or not needed.

#!/bin/bash
# Set -e to exit immediately if any command fails
set -eo pipefail

DOCKER_IMAGE="jaegertracing/jaeger"
CHART_PATH="charts/jaeger/Chart.yaml"

echo "1. Checking latest Docker tag for ${DOCKER_IMAGE}..."

# --- 1. Get the latest semantic version tag by checking the digest of the 'latest' tag ---
# The user states that the 'latest' tag always points to the most recent semver release.
# We first get the unique identifier (digest) of the 'latest' image.
echo "   -> Fetching image digest for 'latest' tag..."
LATEST_DIGEST=$(curl -s "https://registry.hub.docker.com/v2/repositories/${DOCKER_IMAGE}/tags/latest" | \
  jq -r '.images[0].digest')

if [[ -z "$LATEST_DIGEST" || "$LATEST_DIGEST" == "null" ]]; then
  echo "Error: Could not retrieve a valid digest for the 'latest' tag. Exiting."
  exit 1
fi
echo "   -> Latest digest found: ${LATEST_DIGEST}"


# Next, we fetch a list of tags and filter to find the one that:
# 1. Has the exact same digest as 'latest'.
# 2. Matches the semantic version pattern (e.g., 2.39.0).
# NOTE: We still fetch 100 tags to ensure the corresponding semver tag is present,
# but we avoid the CPU-intensive semantic sorting step.
echo "   -> Searching through tags for a semantic version matching this digest..."
LATEST_TAG=$(curl -s "https://registry.hub.docker.com/v2/repositories/${DOCKER_IMAGE}/tags?page_size=100" | \
  jq -r --arg digest "$LATEST_DIGEST" '
    .results[] | 
    select(.images[0].digest == $digest) | 
    .name' | \
  grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' | \
  head -n 1) # Grab the first (and hopefully only) semver match

if [[ -z "$LATEST_TAG" ]]; then
  echo "Error: Could not find a matching semantic version tag (${LATEST_DIGEST}) in the first 100 results. Exiting."
  exit 1
fi

echo "   -> Latest available version is: ${LATEST_TAG}"

# --- 2. Get the current appVersion from Chart.yaml using yq ---
CURRENT_APP_VERSION=$(yq '.appVersion' "$CHART_PATH")

echo "   -> Current appVersion in ${CHART_PATH} is: ${CURRENT_APP_VERSION}"

# --- 3. Compare and update ---
if [[ "$LATEST_TAG" == "$CURRENT_APP_VERSION" ]]; then
  echo "Versions match. No update needed."
  exit 0
fi

echo "Update needed: Changing appVersion from ${CURRENT_APP_VERSION} to ${LATEST_TAG}."

# Use yq to update the appVersion field in place
yq -i ".appVersion = \"$LATEST_TAG\"" "$CHART_PATH"

# --- 4. Configure Git and commit the change ---
# These are necessary steps when a workflow modifies the repository itself.
git config user.name "github-actions[bot]"
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
git add "$CHART_PATH"
git commit -m "chore(deps): Bump appVersion for Jaeger to ${LATEST_TAG}"

# Push the change back to the current branch (needs a PAT or specific GitHub Token permissions)
# NOTE: Using a dedicated Git action (like `peter-evans/create-pull-request`) is generally
# safer and preferred over direct push for creating a PR.
# For a direct push, you might use:
# git push

echo "Successfully updated ${CHART_PATH} and committed the change."

This is the prototype workflow job to create a PR using a bot account

jobs:
  create_automated_pr:
    runs-on: ubuntu-latest
    steps:
      # Use the default GITHUB_TOKEN for checkout, as it only needs read access.
      - name: ⬇️ Checkout repository
        uses: actions/checkout@v4 

      # --- 1. Configure Git for the Bot User ---
      - name: ⚙️ Configure Git
        run: |
          git config user.name "jaegertracingbot"
          git config user.email "[email protected]"
          
      # --- 2. Make Changes & Commit ---
      - name: 🛠️ Make file changes and commit
        id: changes
        run: |
          # 1. Your commands to modify files
          echo "Automated update ran at $(date)" >> README.md
          
          # 2. Check if any changes exist before committing
          if git diff --exit-code; then
            echo "::set-output name=PR_NEEDED::false"
            echo "No changes to commit. Exiting."
          else
            # 3. Commit the changes to the current branch (e.g., 'main' or 'master')
            git add .
            git commit -m "feat: Automated update for dependencies"
            
            # 4. Create and switch to a new topic branch for the PR
            NEW_BRANCH="bot/automate...

</details>



<!-- START COPILOT CODING AGENT TIPS -->
---

✨ Let Copilot coding agent [set things up for you](https://github.com/jaegertracing/helm-charts/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo.

[yurishkuro]

@copilot 1. Do not embed large scripts into the workflow, create them as standalone script under .github/scripts such that it can be tested invidually manually.
2. Do not use yq, the replacements are trivial and can be done with sed or awk
3. Handle the absense of dry_run parameter when running from a cron, e.g. using this trick:

env:
# Use the dry_run input if it exists (workflow_dispatch).
# Otherwise, if the event is 'schedule' (or anything else), default to 'false'.
DRY_RUN: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.dry_run || 'false' }}

[Copilot]

@copilot 1. Do not embed large scripts into the workflow, create them as standalone script under .github/scripts such that it can be tested invidually manually.
2. Do not use yq, the replacements are...

Addressed in 6e5c042:

1. Extracted the script to .github/scripts/update-jaeger-version.sh - can be run standalone with --dry-run flag for testing
2. Replaced yq with sed for the YAML updates
3. Added the DRY_RUN env var pattern you suggested to handle cron runs (defaults to 'false')