Tools/build/compute-changes.py looks at the wrong branches

[JelleZijlstra]

Bug report

Bug description:

Tools/build/compute-changes.py assumes that both of the branches being compared are on the origin origin. This is usually not going to be the case for PR branches. If the PR branch happens to be called main, this can lead to no tests being run, as happened on #131419.

cc @AA-Turner

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• GH-133410: change detection #133409
• GH-133410: Use commit hashes for change detection #133416
• [3.12] GH-133410: Use commit hashes for change detection (gh-133416) #133426
• [3.13] GH-133410: Use commit hashes for change detection (gh-133416) #133427
• gh-133410: Fix PR detection in build workflow #133671
• [3.13] gh-133410: Fix PR detection in build workflow (GH-133671) #134054
• [3.14] gh-133410: Fix PR detection in build workflow (GH-133671) #134055
• [3.12] gh-133410: Fix PR detection in build workflow (GH-133671) #134057

[hugovk]

The PR has broken builds for non-main branches like 3.14 upstream, and also for forks with branches prefixed like 3.14-: #133416 (comment)

It's because the "is this a PR?" check (target_branch and head_ref) isn't working:

cpython/Tools/build/compute-changes.py

Lines 58 to 66 in bfac7d2

	def compute_changes() -> None:
	target_branch, head_ref = git_refs()
	if target_branch and head_ref:
	# Getting changed files only makes sense on a pull request
	files = get_changed_files(target_branch, head_ref)
	outputs = process_changed_files(files)
	else:
	# Otherwise, just run the tests
	outputs = Outputs(run_tests=True, run_windows_tests=True)

And non-main branches (upstream and forks) have both target_branch and head_ref:

target ref: 'main'
head ref: 'ecb77ba1470bbc3e15dd53139f55f34109e7532b'

https://github.com/emmatyping/cpython/actions/runs/14848418162/job/41687428491#step:6:16

target ref: 'main'
head ref: '153496921a05e205d4c45c4a64888ccd43148897'

https://github.com/python/cpython/actions/runs/14907932653/job/41874703388#step:6:91

At least one of them should be false for PRs, but:

• target_branch comes from ${{ github.base_ref || github.event.repository.default_branch }}

  • github.base_ref is only available for PRs, but there should always a fallback default branch

• head_ref comes from ${{ github.event.pull_request.head.sha || github.sha }}

  • similarly, github.event.pull_request.head.sha is only for PRs, but there should always be a fallback github.sha that triggers the workflow

Docs: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs

Let's come up with a better "is this a PR?" check.

[hugovk]

Please see PR #133671.