-
Notifications
You must be signed in to change notification settings - Fork 72
Gated Release Pipeline #1205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Gated Release Pipeline #1205
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1205 +/- ##
==========================================
- Coverage 44.04% 43.10% -0.95%
==========================================
Files 298 299 +1
Lines 27097 32120 +5023
==========================================
+ Hits 11934 13844 +1910
- Misses 14446 17383 +2937
- Partials 717 893 +176
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Add a script to continually poll the CI system status for a commit. It reports if the CI system succeeded for the jobs we care about or not.
83a2685 to
cf32c77
Compare
There was a problem hiding this comment.
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 implements a gated release pipeline that creates draft releases instead of immediately publishing them, allowing maintainers to review before publication. The changes add CI verification to ensure all required checks pass before creating a release, and provide a manual workflow trigger for re-running failed release attempts.
Changes:
- Added CI verification script that polls GitHub's API to check required workflow statuses before allowing release
- Updated release workflow to create draft releases only after CI verification passes
- Added manual workflow trigger capability for re-running release workflow
- Documented the new automatic and manual release processes
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
.github/workflows/release.yml |
Added verification job with tag validation and CI checks, configured release job to create drafts after verification passes, added workflow_dispatch trigger for manual re-runs |
.github/scripts/verify-ci-status.sh |
New script that verifies required CI checks (test shards, kernel variants, k8s tests, OATS tests, markdown linting) have passed on tagged commit, with polling and timeout logic |
RELEASING.md |
Added documentation for automatic release workflow, manual trigger process, and CI verification requirements |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
There was a problem hiding this comment.
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 3 out of 3 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
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 3 out of 3 changed files in this pull request and generated 8 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This comment was marked as resolved.
This comment was marked as resolved.
Directly call all CI workflows needed to validate the code being released is passing our testing and build validation. This accounts for the release commits most often not containing any code changes that trigger these CI workflows and therefore not something we can check happened successfully before releasing.
There was a problem hiding this comment.
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 12 out of 12 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
grcevski
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, but I'm not very good with the CI jobs. Probably good to have someone else approve as well.
There was a problem hiding this comment.
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 12 out of 12 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Validate tag format (must be v*.*.* with numeric components, optional pre-release suffix) | ||
| if ! [[ "$TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+)?$ ]]; then | ||
| echo "ERROR: Tag must match format v*.*.* or v*.*.*-suffix (e.g., v1.2.3 or v1.2.3-rc1), got: $TAG" |
Copilot
AI
Jan 30, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The regex pattern for the pre-release suffix allows only alphanumeric characters ([a-zA-Z0-9]+), which means it would reject valid semantic versioning pre-release identifiers that contain dots or hyphens (e.g., v1.2.3-rc.1, v1.2.3-beta-2). According to semantic versioning (semver), pre-release versions can contain alphanumerics and hyphens, separated by dots. Consider updating the regex to be more permissive, such as ^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.-]+)?$ to support standard semantic versioning formats.
| # Validate tag format (must be v*.*.* with numeric components, optional pre-release suffix) | |
| if ! [[ "$TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+)?$ ]]; then | |
| echo "ERROR: Tag must match format v*.*.* or v*.*.*-suffix (e.g., v1.2.3 or v1.2.3-rc1), got: $TAG" | |
| # Validate tag format (must be v*.*.* with numeric components, optional semver-style pre-release suffix) | |
| if ! [[ "$TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.-]+)?$ ]]; then | |
| echo "ERROR: Tag must match format v*.*.* or v*.*.*-suffix (e.g., v1.2.3, v1.2.3-rc1, v1.2.3-rc.1, v1.2.3-beta-2), got: $TAG" |
| # - publish_dockerhub_main.yml | ||
| # - publish_dockerhub_k8s_cache_main.yml | ||
| - "v*.*.*" | ||
| - "v*.*.*-*" |
Copilot
AI
Jan 30, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a mismatch between the tag trigger pattern and the validation regex. The trigger pattern v*.*.*-* uses wildcards and will match tags like v1.2.3-rc.1 (with dots in the suffix), but the validation regex ^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+)?$ only allows alphanumeric characters in the suffix (no dots or additional hyphens). This means the workflow could be triggered by a tag that then fails validation. Consider either making the trigger pattern more specific or making the validation regex more permissive to handle standard semantic versioning formats.
| - "v*.*.*-*" | |
| - "v*.*.*-[0-9A-Za-z]*" |
Resolve #1200