Docker assessment

[piyushrajput0]

What do these changes do?

This pull request reconstructs the Dockerfile shown in the supplied failed build log, documents the root cause, and adds a corrected fixed.Dockerfile that builds aiohttp successfully. It also adds a focused .dockerignore, reproducible validation evidence, and updates the Labels workflow so the backport job runs only when a non-bot pull request receives a backport* label.

Are there changes in behavior for the user?

There are no aiohttp library or public API behavior changes. Running docker build -t assessment-fix -f fixed.Dockerfile . creates a non-root, pure-Python aiohttp image whose default command verifies the installed package. In CI, ordinary opened, synchronized, reopened, and unrelated-label events no longer fail the backport-label job; the job runs only when a backport* label is added.

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

No. The Docker files are self-contained, and the workflow change is a job-level condition using the existing pull-request event payload. It avoids unnecessary API calls and false failures without changing the backport script's behavior when a backport label is actually added. The image's documented tradeoff is that AIOHTTP_NO_EXTENSIONS=1 disables optional C accelerators for compatibility with the supplied source archive.

Related issue number

No separate issue. This change is submitted as pull request #13331.

Checklist

• I think the code is well written
• Unit tests for the changes exist
  • No aiohttp runtime behavior changed. The Docker build, import smoke test, non-root execution, workflow syntax, and event condition were validated directly.
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
  • Added Piyush Kumar Singh in case-insensitive alphabetical order.
• Add a new news fragment into the CHANGES/ folder
  • Added CHANGES/13331.contrib.rst for pull request Docker assessment #13331.

Validation

docker build --no-cache -t assessment-fix -f fixed.Dockerfile .
# 12/12 stages finished successfully

docker run --rm assessment-fix
# aiohttp 4.0.0a2.dev0 import OK

docker run --rm --entrypoint id assessment-fix
# uid=999(aiohttp) gid=999(aiohttp) groups=999(aiohttp)

docker run --rm -v "${PWD}:/repo" -w /repo rhysd/actionlint:1.7.7 \
  -color .github/workflows/labels.yml
# no findings

python -u tools/check_changes.py
# Check "CHANGES" folder... OK

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.98%. Comparing base (9f42648) to head (1b1e77e).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #13331   +/-   ##
=======================================
  Coverage   98.98%   98.98%           
=======================================
  Files         132      132           
  Lines       49073    49073           
  Branches     2553     2553           
=======================================
  Hits        48576    48576           
  Misses        373      373           
  Partials      124      124           

Flag	Coverage Δ
Autobahn	22.13% <ø> (ø)
CI-GHA	98.90% <ø> (ø)
OS-Linux	98.67% <ø> (+<0.01%)	⬆️
OS-Windows	97.03% <ø> (ø)
OS-macOS	97.93% <ø> (ø)
Py-3.10	98.12% <ø> (ø)
Py-3.11	98.37% <ø> (+<0.01%)	⬆️
Py-3.12	98.46% <ø> (-0.01%)	⬇️
Py-3.13	98.44% <ø> (-0.01%)	⬇️
Py-3.14	98.46% <ø> (ø)
Py-3.14t	97.55% <ø> (+<0.01%)	⬆️
Py-pypy-3.11	97.39% <ø> (-0.03%)	⬇️
VM-macos	97.93% <ø> (ø)
VM-ubuntu	98.67% <ø> (+<0.01%)	⬆️
VM-windows	97.03% <ø> (ø)
cython-coverage	37.96% <ø> (ø)

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

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

[codspeed-hq]

Merging this PR will not alter performance

✅ 84 untouched benchmarks
⏩ 83 skipped benchmarks¹

---

_{Comparing piyushrajput0:docker-assessment (1b1e77e) with master (c0ef574)²}

Footnotes

1. 83 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on master (9f42648) during the generation of this report, so c0ef574 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[pablo-estevez-lrn]

This pull request reconstructs the Dockerfile shown in the supplied failed build log
This looks like the output of an AI, we don't know what is the supplied failed build log if you don't link it.

This PR is committing an MD with the investigation, two dockerfiles and a dockerignore. That dockerfiles are not used anywhere.

I believe this is AI slop. It's really fixing a problem?

[piyushrajput0]

This pull request reconstructs the Dockerfile shown in the supplied failed build log
This looks like the output of an AI, we don't know what is the supplied failed build log if you don't link it.

This PR is committing an MD with the investigation, two dockerfiles and a dockerignore. That dockerfiles are not used anywhere.

I believe this is AI slop. It's really fixing a problem?

Thanks for raising the concern. This PR is a Docker build failure assessment, not a proposal to add or replace aiohttp’s official Docker workflow.

The supplied logs show that an externally generated Docker setup fails because it executes the editable installation before initializing the required llhttp submodule. A subsequent attempt gets further but fails because generated C sources such as aiohttp/_websocket/mask.c are unavailable.

The added artifacts have distinct purposes:

• [original.Dockerfile] is the failing Dockerfile reconstructed from the supplied logs. It is retained as the assessment baseline and is not expected to be executed by the repository.
• [fixed.Dockerfile] is the executable remediation. It builds aiohttp in its supported pure-Python mode with AIOHTTP_NO_EXTENSIONS=1.
• [.dockerignore] is automatically consumed when building from the repository root and prevents Git metadata, caches, and build outputs from entering the build context.

The remediation was tested directly with:

docker build --no-cache -t assessment-fix -f fixed.Dockerfile .
docker run --rm assessment-fix
docker run --rm --entrypoint id assessment-fix

These checks confirm that the image builds successfully, aiohttp imports correctly, and the container runs as a non-root user.

aiohttp already has a separate testing Dockerfile under tools/testing; this assessment does not attempt to replace or modify that workflow because the reported failure comes from the external generated Dockerfile shown in the supplied logs. The standalone files are therefore intentional assessment artifacts. I can make this scope more explicit in the PR description so they are not mistaken for an unused production integration.

[webknjaz]

I think Pablo is right about this being slop at best. Or maybe they're just confused by the concept of cross-repo PRs and experimentation 🤷‍♂️

[webknjaz]

This just keeps happening: #13347. It's like somebody posted the repo in some registry and told people to send nonsense PRs without first learning what contributing actually is…