The GitHub Actions job "npm_and_yarn in /providers/common/ai/src/airflow/providers/common/ai/plugins/www, /ts-sdk for postcss - Update #1503251488" on airflow.git/main has failed. Run started by GitHub user dependabot[bot] (triggered by dependabot[bot]).
Head commit for run: 115eb43aba8b7989be377e682f6cdb2aedb631a0 / Jarek Potiuk <[email protected]> Build docs and registry CI images separately so docs stay on default Python (#70959) * Build docs and registry CI images separately so docs stay on default Python The docs build and the provider registry shared a single CI image, so they also shared its Python. That image is built at 3.12 because the registry has always extracted on 3.12, which silently moved the docs build there too and broke publishing on 2026-07-28: Sphinx mocks third-party modules while building provider docs, and from 3.12 functools copies __type_params__, for which a mock hands back another mock rather than a tuple. Any provider decorating methods with functools.wraps over a mocked callable then fails to import, and the build also began reporting cross-reference ambiguities it had not reported before. The image job already matrixes over the Python versions it is given, and every cache it touches - registry buildx tag, image stash, commit marker and mount cache - is keyed by Python version. Asking it for both versions therefore builds them in parallel, each seeding and storing its own cache, and needs no second job. Docs go back to the default Python and the registry keeps 3.12. The stashes are also named for what they are rather than for the ref alone, so release images stop sharing a key with anything else that stashes an image for the same ref. * Build each CI image in the job that uses it instead of a shared job Docs and the registry now want different Pythons, and a job that builds an image for another job has to hand it over as a multi-gigabyte tarball - exported, stashed, restored and imported - for an image whose only consumer is a single downstream job. Building in place skips that round trip entirely, and the two builds still run in parallel because both jobs now wait only on build-info. What is worth keeping between runs is the BuildKit mount cache rather than the image, so the docs job restores and stashes it under this ref and its own Python. The registry side already knew how to build its own image when the caller had not stashed one; it just could not be told which ref to build, so it would have documented main rather than the tag being published. * Pin the docs build to the default Python again `breeze build-docs` gained a --python option, and because that option reads PYTHON_MAJOR_MINOR_VERSION, which every job of the docs publishing workflow sets, the docs quietly started building on whatever the workflow happened to export rather than on the Python they are meant for. That is how they ended up on 3.12, where Sphinx's mocking of third-party modules makes functools.wraps raise and providers fail to import. Which interpreter documents Airflow is not a per-invocation choice, so the option is gone and the build pins itself to the default again. The workflow reads the same constant instead of naming a version of its own, so the image it prepares cannot drift away from the one the docs build asks for. * Name the docs publishing stashes after the workflow that writes them The prefix exists to keep these images from sharing a key with anything else stashing an image for the same ref, so it should say which workflow put them there rather than describe them as release artifacts. * Build the CI image in the job that uses it, cache and all Each image now has a single consumer, so a job that only builds one can do no more than export it and have the consumer import it straight back. Both docs and the registry build in place instead, which leaves the registry workflow with one job as well. What that job hands to the next run is unchanged: the image, the commit it was built from and the mount cache are stashed under the ref, so a later run for the same ref seeds its build from them and skips the build entirely when the sources have not moved. That is the whole reason the stash exists - publishing an RC and then the final docs is the same ref twice - so it moves into the jobs with the build rather than being dropped along with the job that used to do it. The logic lives in a composite action so both jobs share one copy; ci-image-build.yml stays for callers that do want an image job of their own. * Balance the registry job condition after dropping the image dependency Removing the build-ci-image guard left the parenthesis that opened its group, so GitHub refused to parse the workflow and the dispatch failed before any job ran. * Wait for the registry before reporting the docs publish done The registry still runs alongside the docs build - nothing it does depends on them - but the publish now waits for it, so a green run means both halves of a publish are actually out rather than only the S3 upload. Its result is checked explicitly because the registry is skipped for non-provider distributions, and a skipped dependency would otherwise skip the publish with it. * Read the image-build action from the workflow's own version A local action is resolved against the workspace, not against the ref the workflow definition came from, so publishing a tag cut before the action existed found nothing to run and both image builds failed immediately. The workflow's own version is now checked out alongside the sources being published and the action is taken from there, which is what lets a workflow branch be tested against an older tag at all. The image itself is still built from the checked out sources. Report URL: https://github.com/apache/airflow/actions/runs/30845175894 With regards, GitHub Actions via GitBox --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
