ci: fall back to GitHub-hosted runners on forks

[arthurschreiber]

Description

Today the GitHub Actions workflows pin many jobs to the custom oracle-vm-* self-hosted runner labels. Those runners are only attached to vitessio/vitess, so when a contributor opens a PR inside of their fork, the workflows queue forever (no eligible runner) and ultimately fail.

This PR guards every runs-on that targets a custom runner with github.repository == 'vitessio/vitess', falling back to the standard ubuntu-24.04 runner when the workflow executes outside the main repo. The actual runner choice in vitessio/vitess is unchanged.

docker_build_images.yml is intentionally left alone — its jobs are already gated by if: github.repository == 'vitessio/vitess', so they get skipped on forks and the runner label is never queried.

Related Issue(s)

None.

Checklist

• "Backport to:" labels have been added if this change should be back-ported to release branches
• If this change is to be back-ported to previous releases, a justification is included in the PR description
• Tests were added or are not required
• Did the new or modified tests pass consistently locally and on CI?
• Documentation was added or is not required

Deployment Notes

None — CI-only change. Behavior inside vitessio/vitess is unchanged.

AI Disclosure

This PR was written primarily by Claude Code — I just provided direction.

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.

[Copilot]

Pull request overview

Updates GitHub Actions workflows that currently hard-pin jobs to oracle-vm-* self-hosted runners by adding an expression-based fallback to ubuntu-24.04, intended to prevent jobs from queueing indefinitely when the custom runner labels aren’t available.

Changes:

• Wraps multiple workflow runs-on values with github.repository == 'vitessio/vitess' checks to select oracle-vm-* only in the main repo, else ubuntu-24.04.
• Adjusts matrix-driven runs-on selection in unit_test.yml and cluster_endtoend.yml to incorporate the same repository check.
• Applies the same fallback pattern across the upgrade/downgrade and example workflows.

Reviewed changes

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

Show a summary per file

File	Description
.github/workflows/vtop_example.yml	Adds runs-on fallback from oracle-vm-* to ubuntu-24.04 based on github.repository.
.github/workflows/upgrade_downgrade_test_reparent_old_vttablet.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_reparent_old_vtctl.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_reparent_new_vttablet.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_reparent_new_vtctl.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_query_serving_schema.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_query_serving_schema_next_release.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_query_serving_queries.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_query_serving_queries_next_release.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_query_serving_queries_2.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_query_serving_queries_2_next_release.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_onlineddl_flow.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_backups_manual.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_backups_manual_next_release.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_backups_e2e.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/upgrade_downgrade_test_backups_e2e_next_release.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/unit_test.yml	Gates the race-runner selection with a repository check (oracle runner vs ubuntu).
.github/workflows/region_example.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/local_example.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/codecov.yml	Adds runs-on fallback logic for fork execution.
.github/workflows/cluster_endtoend.yml	Gates the “larger-runner” selection with a repository check (oracle runner vs ubuntu).

[arthurschreiber]

Thanks @copilot-pull-request-reviewer, but resolving these — the suggestion goes the wrong way for what this PR is trying to do.

The intent is to keep using our self-hosted runners whenever the workflow runs inside vitessio/vitess (including pull_request runs from forks, which execute in the base repo's context — so github.repository is vitessio/vitess). The failing case this PR fixes is workflows running inside a contributor's fork (push, schedule, dispatch, etc.), where the custom runner labels aren't available; there github.repository is the fork, and we correctly fall back to ubuntu-24.04.

Switching to github.event.pull_request.head.repo.full_name would force fork-PR jobs onto GitHub-hosted runners (we don't want that), and it's null outside pull_request events anyway, so we'd need a fallback that ends up being github.repository again.

[timvaillancourt]

Nice, this would have saved me a lot of time on previous forks 🚀

[mattlord]

Thanks, @arthurschreiber !