Skip to content

feat(ci): Add advance velox actions#27505

Draft
unidevel wants to merge 1 commit intoprestodb:masterfrom
unidevel:advance-velox
Draft

feat(ci): Add advance velox actions#27505
unidevel wants to merge 1 commit intoprestodb:masterfrom
unidevel:advance-velox

Conversation

@unidevel
Copy link
Copy Markdown
Contributor

@unidevel unidevel commented Apr 4, 2026

Description

Added 2 github actions to create PR and monitor the CI status.

1. velox-advance-pr-create.yml

Creates velox advance PR.

Triggers

  • Scheduled Run (Daily): Runs automatically every day at 09:00 UTC
  • Manual Run: Triggered via workflow_dispatch

Manual Run Modes

Default Mode (force_advance: false)
  • If PR exists: Checks for new changes, notifies if available
  • If no PR: Creates PR if changes available
Force Update Mode (force_advance: true)
  • Updates Velox to latest regardless of existing PR
  • Force-pushes changes to PR branch
  • Updates PR with new commit information

Behavior Details

  • Scheduled Run: Uses master as the base branch
  • Manual Run: Uses the current branch as base branch
  • Automatically updates Velox if changes are available
  • Creates new PR or updates existing one
  • Notifies @prestodb/team-velox when new changes are available on existing PR

2. velox-advance-pr-check.yml

Checks PR CI status and notifies the team.

Triggers

  • Workflow Run: Triggers when test, prestocpp-linux-build, or prestocpp-linux-build-and-unit-test workflows complete on velox-update branch
  • Manual Trigger: Via workflow_dispatch

Behavior

  • Finds the PR associated with velox-update branch
  • Checks current CI status
  • Posts comment to notify @prestodb/team-velox when:
    • CI passes: "CI Checks Passed - This PR is ready for review"
    • CI fails: "CI Checks Failed - Please review the failed checks"

Notification Group

Both workflows use the NOTIFICATION_GROUP environment variable:

  • Default: @prestodb/team-velox
  • Can be overridden via repository variable VELOX_UPDATE_NOTIFICATION_GROUP

Motivation and Context

#24976

Impact

CI

Test Plan

Test in progress

Contributor checklist

  • Please make sure your submission complies with our contributing guide, in particular code style and commit standards.
  • PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
  • Documented new properties (with its default value), SQL syntax, functions, or other functionality.
  • If release notes are required, they follow the release notes guidelines.
  • Adequate tests were added if applicable.
  • CI passed.
  • If adding new dependencies, verified they have an OpenSSF Scorecard score of 5.0 or higher (or obtained explicit TSC approval for lower scores).

Release Notes

Please follow release notes guidelines and fill in the release notes below.

== NO RELEASE NOTE ==

Summary by Sourcery

Add a GitHub Actions workflow to automatically advance the Velox submodule and manage its update PR lifecycle.

New Features:

  • Introduce a scheduled and manually-triggerable workflow to update the Velox submodule and open or refresh a dedicated update pull request.

Enhancements:

  • Automate detection of new Velox commits, PR creation or update, and force-advance behavior via a configurable branch and inputs.
  • Add notification comments and job summary output describing Velox changes and CI outcomes for the update PR.
  • Integrate CI monitoring for the Velox update PR, reporting pass, failure, or timeout back to the PR and workflow summary.

CI:

  • Add a "Advance velox" GitHub Actions workflow that maintains a velox-update branch, manages Velox submodule updates, and tracks CI status for the corresponding PR.

Summary by Sourcery

Add a GitHub Actions workflow to automatically advance the Velox submodule and manage its update PR lifecycle.

New Features:

  • Introduce a scheduled and manually-triggerable GitHub Actions workflow to update the Velox submodule and maintain a dedicated update branch and pull request.

Enhancements:

  • Automate detection of new Velox commits and creation or update of the Velox advance pull request, including optional force-advance behavior.
  • Add PR commenting and step-summary notifications that describe available Velox changes and the current CI outcome for the advance PR.
  • Continuously monitor CI status for the Velox update PR and report success, failure, or timeout back to the PR and workflow summary.

CI:

  • Configure an "Advance velox" CI workflow that runs daily and on demand to keep the Velox submodule up to date and its update PR’s CI status tracked.

@prestodb-ci prestodb-ci added the from:IBM PR from IBM label Apr 4, 2026
@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai bot commented Apr 4, 2026

Reviewer's Guide

Adds a new GitHub Actions workflow, "Advance velox", that automatically or manually advances the Velox submodule, manages a dedicated velox-update branch and PR, and monitors/report CI status for that PR, including notifications to a Velox team mention group.

Sequence diagram for the Advance velox workflow lifecycle

sequenceDiagram
  actor Developer
  participant Scheduler
  participant GithubActions as Github_Actions_Advance_velox
  participant PrestoRepo as Presto_Repository
  participant VeloxRepo as Velox_Repository
  participant PRs as Pull_Requests
  participant CI as CI_Workflows
  participant VeloxTeam as Velox_Team

  alt Scheduled_run
    Scheduler->>GithubActions: Trigger_workflow(event_name=schedule)
  else Manual_run
    Developer->>GithubActions: Trigger_workflow_dispatch(force_advance)
  end

  GithubActions->>PrestoRepo: Checkout(BASE_BRANCH, submodules_recursive)
  GithubActions->>PrestoRepo: Check_for_existing_PR(head=velox_update_branch, base=BASE_BRANCH)
  GithubActions->>VeloxRepo: Determine_current_and_latest_Velox_commits

  alt PR_exists_and_new_changes_and_not_FORCE_ADVANCE
    GithubActions->>PRs: Comment_new_changes_available
    GithubActions->>PRs: Determine_PR_for_CI_monitoring
  else No_PR_or_FORCE_ADVANCE_and_new_changes
    GithubActions->>PrestoRepo: Update_Velox_submodule_to_latest
    GithubActions->>PrestoRepo: Commit_and_push_to_velox_update_branch
    GithubActions->>PRs: Create_or_update_PR
  else No_new_changes
    GithubActions-->>Developer: Summary_Velox_up_to_date
  end

  opt PR_for_monitoring_available
    GithubActions->>PRs: Wait_for_CI_checks_to_start
    PRs->>CI: Trigger_CI_workflows
    loop Until_success_failure_or_timeout
      GithubActions->>PRs: Query_PR_checks_status
      PRs-->>GithubActions: Checks_states
    end

    alt CI_success
      GithubActions->>PRs: Comment_CI_passed
      GithubActions->>VeloxTeam: Mention_ready_for_review
    else CI_failure
      GithubActions->>PRs: Comment_CI_failed
      GithubActions->>VeloxTeam: Mention_review_failures
    else CI_timeout
      GithubActions->>PRs: Comment_CI_timeout
      GithubActions->>VeloxTeam: Mention_manual_check_needed
    end

    GithubActions-->>Developer: Write_workflow_summary
  end
Loading

File-Level Changes

Change Details Files
Introduce an "Advance velox" GitHub Actions workflow that advances the Velox submodule, manages the velox-update PR lifecycle, and monitors CI with notifications and run summaries.
  • Add scheduled and workflow_dispatch triggers with a force_advance input and shared env configuration for base branch, update branch, notification group, and force behavior.
  • Implement logic to detect an existing velox-update PR, determine current vs latest Velox commits, and decide whether to only notify or to actually advance the submodule.
  • When advancing, update the Velox submodule to origin/main, detect changes, create/update the velox-update branch, and open or edit a PR with a standardized title and body.
  • Add CI monitoring that polls PR checks for up to 5 hours, classifies success/failure/timeout, and posts corresponding comments tagging the notification group.
  • Generate a detailed workflow run summary describing whether Velox was already up to date, new changes are available, what commit it was advanced to, and the final CI result, failing the job on CI failure/timeout.
.github/workflows/velox-submodule-update.yml

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@unidevel unidevel force-pushed the advance-velox branch 2 times, most recently from c29efac to 19cb438 Compare April 4, 2026 12:01
@unidevel
Copy link
Copy Markdown
Contributor Author

unidevel commented Apr 4, 2026

@sourcery-ai review

Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

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

Hey - I've found 2 issues, and left some high level feedback:

  • The CI monitoring loop is configured for up to 5 hours (600 * 30 seconds) but the log and PR messages say it times out after 30 minutes, so the timeout messaging should be updated or the loop limits adjusted to match the stated duration.
  • Consider adding a concurrency group for this workflow (e.g., keyed by the Velox update branch) to prevent overlapping scheduled and manual runs from racing on the same branch and PR.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The CI monitoring loop is configured for up to 5 hours (600 * 30 seconds) but the log and PR messages say it times out after 30 minutes, so the timeout messaging should be updated or the loop limits adjusted to match the stated duration.
- Consider adding a concurrency group for this workflow (e.g., keyed by the Velox update branch) to prevent overlapping scheduled and manual runs from racing on the same branch and PR.

## Individual Comments

### Comment 1
<location path=".github/workflows/velox-submodule-update.yml" line_range="34" />
<code_context>
+          submodules: recursive
+          token: ${{ secrets.GITHUB_TOKEN }}
+          ref: ${{ env.BASE_BRANCH }}
+          persist-credentials: false
+
+      - name: Configure Git
</code_context>
<issue_to_address>
**issue (bug_risk):** Pushing the branch is likely to fail because Git credentials are not persisted after checkout.

Because `actions/checkout` is run with `persist-credentials: false`, the token used for checkout is removed and the later `git push -f origin "$VELOX_UPDATE_BRANCH"` will run without auth. To fix this, either remove `persist-credentials: false` so credentials remain configured, or explicitly set the remote with the workflow token before pushing, e.g.
```bash
git remote set-url origin "https://x-access-token:${GITHUB_TOKEN}@github.com/${GITHUB_REPOSITORY}.git"
```
</issue_to_address>

### Comment 2
<location path=".github/workflows/velox-submodule-update.yml" line_range="277-286" />
<code_context>
+          MAX_ATTEMPTS=600  # Wait up to 5 hours (600 * 30 seconds)
</code_context>
<issue_to_address>
**nitpick:** CI timeout messages are inconsistent with the actual wait time (5 hours vs 30 minutes).

The loop runs for up to 600 × 30s = 5 hours, but the final log says:
```bash
echo "CI monitoring timed out after 30 minutes"
```
This inconsistency can mislead anyone reading the logs.

Please update the timeout message (and the notification body that uses similar wording) to match the actual 5-hour window, or reduce `MAX_ATTEMPTS` if you intend a 30-minute timeout instead.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@unidevel unidevel force-pushed the advance-velox branch 3 times, most recently from 49978fa to 2cde290 Compare April 4, 2026 12:40
@unidevel
Copy link
Copy Markdown
Contributor Author

unidevel commented Apr 4, 2026

@sourcery-ai review

Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

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

Hey - I've found 1 issue, and left some high level feedback:

  • The CI monitoring loop waits up to 5 hours in a single job (MAX_ATTEMPTS=600 with 30-second sleeps), which can consume a lot of runner time and approach GitHub’s max job duration; consider shortening the timeout and/or splitting monitoring into a separate, re-runnable workflow or job using workflow_run or scheduled polling.
  • The workflow logic for FORCE_ADVANCE and PR existence is fairly intricate, with multiple conditionals controlling when branches are updated vs. only monitored; adding small helper scripts or composite actions to encapsulate the "check PR", "update submodule & branch", and "monitor CI" phases would reduce duplication and make the control flow easier to reason about.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The CI monitoring loop waits up to 5 hours in a single job (`MAX_ATTEMPTS=600` with 30-second sleeps), which can consume a lot of runner time and approach GitHub’s max job duration; consider shortening the timeout and/or splitting monitoring into a separate, re-runnable workflow or job using `workflow_run` or scheduled polling.
- The workflow logic for `FORCE_ADVANCE` and PR existence is fairly intricate, with multiple conditionals controlling when branches are updated vs. only monitored; adding small helper scripts or composite actions to encapsulate the "check PR", "update submodule & branch", and "monitor CI" phases would reduce duplication and make the control flow easier to reason about.

## Individual Comments

### Comment 1
<location path=".github/workflows/velox-submodule-update.yml" line_range="302-305" />
<code_context>
+            # Get all states
+            STATES=$(echo "$CHECKS_JSON" | jq -r '.[].state' | sort -u)
+
+            # Check if all checks are completed (no PENDING, QUEUED, or IN_PROGRESS)
+            if ! echo "$STATES" | grep -qE "PENDING|QUEUED|IN_PROGRESS"; then
+              # All checks completed, check for failures
+              if echo "$STATES" | grep -qE "FAILURE|CANCELLED|TIMED_OUT|ERROR"; then
+                echo "ci_result=failure" >> $GITHUB_OUTPUT
+                echo "CI checks failed"
</code_context>
<issue_to_address>
**issue:** Handle neutral or skipped CI states to avoid timing out when no job is actually running.

Currently, the loop only terminates on SUCCESS or explicit failure states. If all checks end up SKIPPED/NEUTRAL (or other non-running states that don’t match these patterns), the loop never exits and we hit the 5‑hour timeout. Please treat a set of only non-running, non-success, non-failure states (e.g., all SKIPPED) as a terminal condition and set `ci_result` accordingly (success or a dedicated status) instead of timing out.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@unidevel unidevel force-pushed the advance-velox branch 2 times, most recently from b14ccd9 to 04faea9 Compare April 5, 2026 12:04
@unidevel unidevel changed the title feat(ci): Add advance velox action feat(ci): Add advance velox actions Apr 5, 2026
# If force_advance is true, always use base branch (treat as new PR)
# If PR exists and not forcing, use commit from PR branch
# Otherwise use base branch
if [ "$FORCE_ADVANCE" = "true" ]; then
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.

Maybe we can simply this?
If the PR doesn't exist or we are forcing we use

CURRENT_COMMIT=$(git ls-tree "origin/$VELOX_UPDATE_BRANCH" presto-native-execution/velox | awk '{print $3}')

else we use existing commit

CURRENT_COMMIT=$(git ls-tree "origin/$VELOX_UPDATE_BRANCH" presto-native-execution/velox | awk '{print $3}')

Could we simplify this into a single if-else? Aka we are not forcing and PR exists in the if?

- name: Update Velox submodule
if: (steps.check_pr.outputs.pr_exists != 'true' || env.FORCE_ADVANCE == 'true') && steps.check_new_changes.outputs.new_changes_available == 'true'
run: |
git -C presto-native-execution/velox checkout main
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.

Let's use git switch main (aka use the newer git API for handling the branches.

git remote set-url origin "https://x-access-token:${GITHUB_TOKEN}@github.com/${GITHUB_REPOSITORY}.git"

# Ensure we're on the base branch
git checkout "$BASE_BRANCH"
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.

git switch "$BASE_BRANCH"

# Ensure we're on the base branch
git checkout "$BASE_BRANCH"
# Create and switch to new branch (or switch if it exists)
git checkout -B "$VELOX_UPDATE_BRANCH"
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.

git switch -C "$VELOX_UPDATE_BRANCH"
(also updates the commit).

# Stage the submodule changes
git add presto-native-execution/velox
# Commit the changes
git commit -m "Update Velox submodule to $VELOX_COMMIT"
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.

Lets match the commit message with the PR abstract below.
"chore(ci): Advance velox ($(date +'%Y-%m-%d'))"

if [ -n "$CHECK_PR_NUMBER" ] || [ -n "$CREATE_PR_NUMBER" ]; then
echo "should_monitor=true" >> $GITHUB_OUTPUT
else
echo "should_monitor=false" >> $GITHUB_OUTPUT
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.

I see pr_url being used in the summary to add it to the PR description, so the pr-check job can pick it up.
But I don't see should_monitor being put into the description.

@unidevel
Copy link
Copy Markdown
Contributor Author

unidevel commented Apr 5, 2026

@czentgr Thanks for your review. I’d like to take some time to go through the flow and refactor it. I’ll let you know once it’s ready for review.

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

Labels

from:IBM PR from IBM

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants