Backport: Skip pull_request triggered runs in private repos - 6.1 Branch

[desrosj]

This backports 15c4b04 (r63183) to the 6.1 branch.

Merge Conflict Resolution

The cherry-pick conflicted. The 6.1 branch has only 6 workflow files in the affected family (plus welcome-new-contributors.yml, which is out of scope), so a majority of the original commit's hunks do not apply here.

Files updated (7 jobs across 6 files)

All received the canonical replacement condition:

• .github/workflows/coding-standards.yml — phpcs and jshint jobs
• .github/workflows/end-to-end-tests.yml — e2e-tests job
• .github/workflows/javascript-tests.yml — test-js job
• .github/workflows/php-compatibility.yml — php-compatibility job
• .github/workflows/phpunit-tests.yml — test-php job
• .github/workflows/test-build-processes.yml — test-core-build-process job

Conflicts and how they were resolved

• coding-standards.yml (content conflict) — On 6.1 the phpcs job has an extra with: php-version: '7.4' block immediately following the if: line, which trunk does not have. Resolved by taking the new multi-line if: condition and preserving the existing with: block after it. The jshint job auto-merged cleanly.
• php-compatibility.yml (content conflict) — Same cause and same resolution: 6.1's php-compatibility job carries a with: php-version: '7.4' block after the if: line. New condition applied, with: block preserved.
• phpunit-tests.yml (content conflict) — This file has diverged substantially between 6.1 and trunk. The cherry-pick attempted to introduce trunk-only content that does not belong on this branch: a prepare-gutenberg job, the test-with-mariadb / fork-specific test jobs, secrets: blocks listing CODECOV_TOKEN / WPT_REPORT_API_KEY (6.1 uses secrets: inherit), and gutenberg-artifact / gutenberg-sha inputs. Rather than untangle the merge, the file was reset to the 6.1 version (git checkout upstream/6.1 -- .github/workflows/phpunit-tests.yml) and the condition was hand-applied to the single test-php job. 6.1 has none of the startsWith( github.repository, 'WordPress/' ) job variants nor the fork-only job from trunk, so only the plain canonical form was needed.
• end-to-end-tests.yml, javascript-tests.yml, test-build-processes.yml — auto-merged cleanly, no manual intervention.

Hunks dropped (files do not exist on 6.1)

These files were reported as modify/delete conflicts and were git rm'd, since they do not exist on this branch and no equivalent file exists either:

• .github/workflows/javascript-type-checking.yml
• .github/workflows/performance.yml
• .github/workflows/phpstan-static-analysis.yml
• .github/workflows/test-and-zip-default-themes.yml
• .github/workflows/upgrade-develop-testing.yml (no upgrade-testing.yml equivalent on 6.1 either)
• .github/workflows/workflow-lint.yml

Because upgrade-develop-testing.yml and workflow-lint.yml do not exist here, the accompanying uses: WordPress/wordpress-develop/.github/workflows/<x>.yml@trunk → uses: ./.github/workflows/<x>.yml change from the original commit was not carried over. 6.1 also has no local reusable-*.yml workflow files, so that change would not have been valid on this branch regardless.

Intentionally left alone

• Slack notification jobs in all files — gated on github.event_name != 'pull_request' and unaffected.
• test-build-processes.yml test-build-scripts job (if: ${{ github.repository == 'WordPress/wordpress-develop' }}) — not part of the targeted condition family.
• welcome-new-contributors.yml — out of scope.

Verification

• git diff upstream/6.1 --stat shows only files under .github/workflows/.
• No conflict markers remain.
• All workflow YAML files parse successfully.
• No instances of the old || github.event_name == 'pull_request' form remain in .github/workflows/.

Use of AI Tools

This pull request was created by an AI agent (Claude Code). Until this PR is marked "Ready for Review", treat it as untrusted, AI-created code that requires a manual review by a human team member.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.