[PR #11737/f30f43e6 backport][3.14] Skip benchmarks in ci when running in fork repositories

[rodrigobnogueira]

Description

What do these changes do?

This is a backport of PR #11737 to the 3.14 branch.

Forks cannot use codspeed account, which can make benchmark job in ci fail if aiohttp contributors want to run test workflow on their forks. This change makes unnecessary steps skip if the triggered workflow is not in the main repository.

Are there changes in behavior for the user?

aiohttp contributors can now run github action workflows to test changes in their forks without unnecessary errors.

Is it a substantial burden for the maintainers to support this?

No, this is a straightforward CI configuration change.

Related issue number

Backport of #11737

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
• Add a new news fragment into the CHANGES/ folder

[webknjaz]

Sometimes, when GitHub has troubles, it doesn't deliver webhook events to integrations (including GHA CI). In this case, closing+reopening the PR when GH outage is over, triggers it and other automations properly.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.22%. Comparing base (2b6bb4b) to head (fe5d064).
⚠️ Report is 5 commits behind head on 3.14.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             3.14   #11991   +/-   ##
=======================================
  Coverage   98.22%   98.22%           
=======================================
  Files         128      128           
  Lines       44990    44990           
  Branches     2434     2434           
=======================================
+ Hits        44190    44192    +2     
+ Misses        618      615    -3     
- Partials      182      183    +1     

Flag	Coverage Δ
CI-GHA	98.10% <ø> (+<0.01%)	⬆️
OS-Linux	97.86% <ø> (+<0.01%)	⬆️
OS-Windows	95.60% <ø> (ø)
OS-macOS	97.11% <ø> (+<0.01%)	⬆️
Py-3.10.11	96.64% <ø> (ø)
Py-3.10.19	97.13% <ø> (+<0.01%)	⬆️
Py-3.11.14	97.37% <ø> (-0.01%)	⬇️
Py-3.11.9	96.88% <ø> (ø)
Py-3.12.10	96.97% <ø> (ø)
Py-3.12.12	97.46% <ø> (-0.01%)	⬇️
Py-3.13.11	97.69% <ø> (+<0.01%)	⬆️
Py-3.14.2	97.67% <ø> (+<0.01%)	⬆️
Py-3.14.2t	96.76% <ø> (-0.01%)	⬇️
Py-pypy3.11.13-7.3.20	96.91% <ø> (+<0.01%)	⬆️
VM-macos	97.11% <ø> (+<0.01%)	⬆️
VM-ubuntu	97.86% <ø> (+<0.01%)	⬆️
VM-windows	95.60% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will not alter performance

✅ 59 untouched benchmarks

---

_{Comparing rodrigobnogueira:backport/11737-to-3.14 (fe5d064) with 3.14 (2b6bb4b)¹}

Footnotes

1. No successful run was found on 3.14 (500b2b5) during the generation of this report, so 2b6bb4b was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Dreamsorcerer]

Sometimes, when GitHub has troubles, it doesn't deliver webhook events to integrations (including GHA CI). In this case, closing+reopening the PR when GH outage is over, triggers it and other automations properly.

FYI, I'm finding that increasingly rare these days. Most of the time now it's just because there's no runners available or the previous commit's workflow is still cancelling, and it then works once it's caught up.

[webknjaz]

Yeah, it depends. But sometimes GH disables webhook deliveries at the time of big outages manually. They the re-enable them once they fixed things. But they never retroactively deliver those events that happened during that period.

This was mostly an educational comment for Rodrigo, though, since he tried achieving the same by pushing empty commits.