Skip to content

Centralize build scheduling into a single version-aware dispatcher - #46

Open
kaovilai with Copilot wants to merge 5 commits into
mainfrom
copilot/refactor-workflows-for-efficiency
Open

Centralize build scheduling into a single version-aware dispatcher#46
kaovilai with Copilot wants to merge 5 commits into
mainfrom
copilot/refactor-workflows-for-efficiency

Conversation

Copilot AI commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Each of the six image build workflows (ubi8/9/10 and their OpenSSL FIPS variants) ran its own weekly schedule, rebuilding every version regardless of whether anything upstream changed. This centralizes scheduling into one workflow that dispatches builds only when a newer Go version is available than what's published in quay.io/konveyor/builder.

Changes

  • New scheduled_dispatch.yml — the single scheduled entry point (0 0 * * 6, plus manual workflow_dispatch with a dry_run toggle). It:
    • Resolves supported Go versions from go.dev (standard images) and golang-fips/go releases (FIPS images), reusing the FIPS selection logic from the existing workflow.
    • Lists published tags from the Quay API and dispatches a build workflow only when its expected version tag is missing (latest → empty go_version; previous → explicit version).
  • Removed the schedule: trigger from all six build workflows; they now run on workflow_dispatch, push, and pull_request only. PR validation behavior is unchanged.

Tag scheme used for comparison

ubi8 publishes with no prefix; ubi9/ubi10 are prefixed:

v<ver>                      ubi9-v<ver>              ubi10-v<ver>
openssl-fips-v<ver>         ubi9-openssl-fips-v<ver> ubi10-openssl-fips-v<ver>

Reviewer note

Uses the built-in GITHUB_TOKEN with permissions: actions: write. workflow_dispatch API calls are an explicit exception to the GITHUB_TOKEN recursion guard, so no additional PAT or secret is required.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR consolidates weekly build scheduling into a single GitHub Actions workflow that checks upstream Go/FIPS versions against tags already published to quay.io/konveyor/builder, and dispatches only the missing version builds. This reduces unnecessary rebuilds across the six existing image build workflows.

Changes:

  • Added a new scheduled dispatcher workflow that queries upstream Go/FIPS versions and Quay tags, then triggers the appropriate build workflows when tags are missing.
  • Removed the schedule: trigger from all six existing build workflows so they only run via workflow_dispatch, push, and pull_request.
  • Implemented a dry_run mode for the dispatcher to log intended dispatches.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 8 comments.

Show a summary per file
File Description
.github/workflows/scheduled_dispatch.yml New centralized scheduled workflow that compares upstream versions to Quay tags and dispatches builds when needed.
.github/workflows/ubi8_multi_arch_image_build.yml Removed weekly schedule trigger.
.github/workflows/ubi9_multi_arch_image_build.yml Removed weekly schedule trigger.
.github/workflows/ubi10_multi_arch_image_build.yml Removed weekly schedule trigger.
.github/workflows/ubi8_openssl_fips_multi_arch_image_build.yml Removed weekly schedule trigger.
.github/workflows/ubi9_openssl_fips_multi_arch_image_build.yml Removed weekly schedule trigger.
.github/workflows/ubi10_openssl_fips_multi_arch_image_build.yml Removed weekly schedule trigger.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +124 to +126
echo "Checking OpenSSL FIPS image versions ..."
fips_releases=$(gh api repos/golang-fips/go/releases --paginate)
mapfile -t FIPS_ENTRIES < <(echo "$fips_releases" | jq -r '
Comment on lines +100 to +103
echo "Checking standard (non-FIPS) image versions ..."
go_json=$(curl -sfS --retry 3 --retry-delay 5 --max-time 30 'https://go.dev/dl/?mode=json')
mapfile -t GO_VERSIONS < <(echo "$go_json" | jq -r '[.[] | select(.stable == true) | .version | ltrimstr("go")] | .[]')

Comment on lines 10 to 14
push:
paths:
- 'Dockerfile.ubi8'
- '.github/workflows/ubi8_multi_arch_image_build.yml'
schedule:
- cron: '0 0 * * 6'
pull_request:
Comment on lines 10 to 14
push:
paths:
- 'Dockerfile.ubi9'
- '.github/workflows/ubi9_multi_arch_image_build.yml'
schedule:
- cron: '0 0 * * 6'
pull_request:
Comment on lines 10 to 14
push:
paths:
- 'Dockerfile.ubi10'
- '.github/workflows/ubi10_multi_arch_image_build.yml'
schedule:
- cron: '0 0 * * 6'
pull_request:

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was already addressed in commit 1f38d76 — the condition was simplified from "schedule" || "pull_request" to just "pull_request", and the comment updated accordingly.

Comment on lines 10 to 14
push:
paths:
- 'Dockerfile.ubi8-openssl-fips'
- '.github/workflows/ubi8_openssl_fips_multi_arch_image_build.yml'
schedule:
- cron: '0 2 * * 6'
pull_request:
Comment on lines 10 to 14
push:
paths:
- 'Dockerfile.ubi9-openssl-fips'
- '.github/workflows/ubi9_openssl_fips_multi_arch_image_build.yml'
schedule:
- cron: '0 2 * * 6'
pull_request:
Comment on lines 10 to 14
push:
paths:
- 'Dockerfile.ubi10-openssl-fips'
- '.github/workflows/ubi10_openssl_fips_multi_arch_image_build.yml'
schedule:
- cron: '0 2 * * 6'
pull_request:
@kaovilai

Copy link
Copy Markdown
Member

GitHub’s docs say that events created with GITHUB_TOKEN usually do not trigger new workflow runs, but workflow_dispatch and repository_dispatch are explicit exceptions and always create workflow runs. See GITHUB_TOKEN.

@copilot address the review and use the built-in GitHub token.

Copilot AI commented Jul 16, 2026

Copy link
Copy Markdown
Contributor Author

GitHub’s docs say that events created with GITHUB_TOKEN usually do not trigger new workflow runs, but workflow_dispatch and repository_dispatch are explicit exceptions and always create workflow run...

Done in Address review: use GITHUB_TOKEN, limit Go versions, remove dead schedule branches. Changes made:

  • scheduled_dispatch.yml: Switched GH_TOKEN from secrets.WORKFLOW_DISPATCH_TOKEN to github.token. Removed the missing-token error check and updated the header comment to note that workflow_dispatch is an explicit exception. Also capped standard Go versions to .[0:2] to avoid unexpected backfill dispatches if the go.dev API ever returns more stable entries.
  • All 6 build workflows: Removed the unreachable schedule branch from each determine-versions script (now just checks for pull_request).

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Comment on lines +12 to +14
# workflow_dispatch events are an explicit exception to the rule that
# GITHUB_TOKEN cannot trigger new workflow runs, so no additional token is
# required (see https://docs.github.com/en/actions/concepts/security/github_token).
Comment on lines +34 to +36
env:
GH_TOKEN: ${{ github.token }}
DRY_RUN: ${{ github.event_name == 'workflow_dispatch' && inputs.dry_run || false }}
Comment on lines +38 to +42
- name: Check version availability and dispatch builds
run: |
set -euo pipefail

# --- Standard (non-FIPS) image variants ---------------------------------
@kaovilai

Copy link
Copy Markdown
Member

Note

Responses generated with Claude

@copilot Two things to fix on this PR:

  1. PR description contradicts the implementation. The "Reviewer note" section says:

    Requires a WORKFLOW_DISPATCH_TOKEN secret (PAT or GitHub App token with actions: write). The default GITHUB_TOKEN cannot trigger downstream workflow_dispatch runs (recursion guard), so dispatched builds would silently not start without it. The workflow fails fast with a clear message if the secret is absent.

    But scheduled_dispatch.yml never references a WORKFLOW_DISPATCH_TOKEN secret and has no fail-fast check for it — it uses GH_TOKEN: ${{ github.token }} with permissions: actions: write, and the in-file comment correctly notes that workflow_dispatch API calls are an explicit exception to the GITHUB_TOKEN recursion guard (per GitHub's docs). That's the correct approach — keep GH_TOKEN: ${{ github.token }} as-is. Please just update/remove the stale "Reviewer note" in the PR description so it matches what's actually shipped, since it'll confuse future reviewers/maintainers into thinking a PAT secret needs to be provisioned.

  2. Minor: no concurrency guard on scheduled_dispatch.yml. If someone manually re-runs it (e.g. via workflow_dispatch) while a scheduled run is still in flight, both could dispatch the same builds twice. Consider adding a concurrency: { group: scheduled-dispatch, cancel-in-progress: false } block. Optional, low severity.

Everything else (tag-matching logic between this dispatcher and each build workflow's published v<ver> / ubi9-v<ver> / openssl-fips-v<ver> tags, the FIPS version-dedup logic, the dry_run toggle) checks out correctly.

Copilot AI commented Jul 20, 2026

Copy link
Copy Markdown
Contributor Author

[!Note]
Responses generated with Claude
...

Added the concurrency guard in 1b39555.

For the PR description: I don't have a way to directly edit the PR body through the available tools. Could you update the "Reviewer note" section manually? The stale text to remove/replace is:

Requires a WORKFLOW_DISPATCH_TOKEN secret (PAT or GitHub App token with actions: write). The default GITHUB_TOKEN cannot trigger downstream workflow_dispatch runs (recursion guard), so dispatched builds would silently not start without it. The workflow fails fast with a clear message if the secret is absent.

It can be removed entirely, or replaced with something like:

Uses the built-in GITHUB_TOKEN with permissions: actions: write. workflow_dispatch API calls are an explicit exception to the GITHUB_TOKEN recursion guard, so no additional PAT or secret is required.

@kaovilai
kaovilai marked this pull request as ready for review July 21, 2026 00:20
@kaovilai

Copy link
Copy Markdown
Member

@copilot .github/workflows/scheduled_dispatch.yml should also run when .github/workflows/scheduled_dispatch.yml changes.

Copilot AI commented Jul 21, 2026

Copy link
Copy Markdown
Contributor Author

@copilot .github/workflows/scheduled_dispatch.yml should also run when .github/workflows/scheduled_dispatch.yml changes.

Added in ef9aa44scheduled_dispatch.yml now includes a push trigger scoped to .github/workflows/scheduled_dispatch.yml.

@kaovilai

Copy link
Copy Markdown
Member

@copilot add retries

  • name: wait for image digests...
    run: |
    set -euo pipefail

    for digest in /tmp/digests/*; do
    digest="sha256:$(basename "$digest")"

    for attempt in {1..6}; do
      if docker buildx imagetools inspect \
        "quay.io/konveyor/builder@${digest}" >/dev/null 2>&1; then
        break
      fi
    
      if [ "$attempt" -eq 6 ]; then
        echo "Digest unavailable after retries: ${digest}"
        exit 1
      fi
    
      echo "Waiting for Quay to expose ${digest} (attempt ${attempt}/6)"
      sleep 10
    done
    

    done

Copilot AI commented Aug 11, 2026

Copy link
Copy Markdown
Contributor Author

@copilot add retries

  • name: wait for image digests...
    ...

Added in 69ca031 — the wait for image digests... step with the 6-attempt retry loop is now in all 6 build workflows (ubi8/9/10 and their FIPS variants), inserted after download digests... and before login to Quay.io... in each merge job.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants