feat(ci): central scheduled-builds dispatcher with stateless version rotation#361
Open
yuravk wants to merge 1 commit into
Open
feat(ci): central scheduled-builds dispatcher with stateless version rotation#361yuravk wants to merge 1 commit into
yuravk wants to merge 1 commit into
Conversation
…rotation Add scheduled-builds.yml - the only workflow with an on.schedule trigger. When a cron fires it converts the firing into a real workflow_dispatch of the target unified workflow via `gh workflow run`, passing version_major as a genuine input (the other inputs take their dispatch defaults automatically). The build workflows therefore carry no schedule handling or input emulation, and their version-aware run-name works natively. Version selection is a stateless rotation - weeks since the Unix epoch modulo the VERSIONS list (8, 9, 10, 10-kitten) - so every version builds every 4 weeks with no day-of-month coupling and no stored state; adding a major is one list entry and the cycle stretches automatically. Image-type selection is arithmetic too: the firing cron's hour encodes the type (index = (hour - 2) / 2 into TYPES), giving a 2-hour stagger between image types on Mondays (UTC): 02:17 opennebula-build-test 08:17 azure-build-release-test-publish 04:17 gencloud-build-test 10:17 oci-build-release-test-publish 06:17 aws-build-test-copy-release 12:17 vagrant-build-test-publish Minute 17 avoids the congested top-of-the-hour cron slot. gcp-build-test-publish.yml is deliberately not scheduled. Dispatching with defaults means the FULL pipeline runs, publishing included - a scheduled firing is a real release cycle (AWS releases AMIs + Marketplace + wiki PR, Vagrant publishes boxes to HCP, Azure releases to the gallery + Marketplace drafts, OCI submits a Marketplace draft; tests gate publishing inside each workflow). Version quirks are handled in the dispatch loop: AWS spells Kitten 'kitten_10' (translated), OCI has no Kitten option (skipped on Kitten weeks). Scheduled firings run only in the AlmaLinux org's almalinux/cloud-images repository; manual workflow_dispatch runs (target_workflow + an optional version override, 'rotation' = what this week's schedule would build) work anywhere for testing and dispatch on the current ref. Uses the default GITHUB_TOKEN with actions:write - workflow_dispatch is exempt from the no-runs-from-GITHUB_TOKEN-events rule, so no PAT is needed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add scheduled-builds.yml - the only workflow with an on.schedule trigger. When a cron fires it converts the firing into a real workflow_dispatch of the target unified workflow via
gh workflow run, passing version_major as a genuine input (the other inputs take their dispatch defaults automatically). The build workflows therefore carry no schedule handling or input emulation, and their version-aware run-name works natively.Version selection is a stateless rotation - weeks since the Unix epoch modulo the VERSIONS list (8, 9, 10, 10-kitten) - so every version builds every 4 weeks with no day-of-month coupling and no stored state; adding a major is one list entry and the cycle stretches automatically.
Image-type selection is arithmetic too: the firing cron's hour encodes the type (index = (hour - 2) / 2 into TYPES), giving a 2-hour stagger between image types on Mondays (UTC):
02:17 opennebula-build-test 08:17 azure-build-release-test-publish
04:17 gencloud-build-test 10:17 oci-build-release-test-publish
06:17 aws-build-test-copy-release 12:17 vagrant-build-test-publish
Minute 17 avoids the congested top-of-the-hour cron slot.
gcp-build-test-publish.yml is deliberately not scheduled.
Dispatching with defaults means the FULL pipeline runs, publishing included - a scheduled firing is a real release cycle (AWS releases AMIs + Marketplace + wiki PR, Vagrant publishes boxes to HCP, Azure releases to the gallery + Marketplace drafts, OCI submits a Marketplace draft; tests gate publishing inside each workflow). Version quirks are handled in the dispatch loop: AWS spells Kitten 'kitten_10' (translated), OCI has no Kitten option (skipped on Kitten weeks).
Scheduled firings run only in the AlmaLinux org's almalinux/cloud-images repository; manual workflow_dispatch runs (target_workflow + an optional version override, 'rotation' = what this week's schedule would build) work anywhere for testing and dispatch on the current ref. Uses the default GITHUB_TOKEN with actions:write - workflow_dispatch is exempt from the no-runs-from-GITHUB_TOKEN-events rule, so no PAT is needed.