Skip to content

Bump base image to 2026.02.0 with Python 3.14.3, use 3.14.3 in CI#162263

Closed
sairon wants to merge 1 commit intodevfrom
python-3.14.3
Closed

Bump base image to 2026.02.0 with Python 3.14.3, use 3.14.3 in CI#162263
sairon wants to merge 1 commit intodevfrom
python-3.14.3

Conversation

@sairon
Copy link
Copy Markdown
Member

@sairon sairon commented Feb 5, 2026

Proposed change

This also bumps libcec used in the base image to 7.1.1, full changelog:

Python changelog:

CI Failures to be fixed

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:
  • Link to developer documentation pull request:
  • Link to frontend pull request:

Checklist

  • I understand the code I am submitting and can explain how it works.
  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.
  • Any generated code has been carefully reviewed for correctness and compliance with project standards.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies a diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

@sairon sairon requested a review from edenhaus February 5, 2026 07:23
@sairon sairon requested a review from a team as a code owner February 5, 2026 07:23
Copilot AI review requested due to automatic review settings February 5, 2026 07:23
@home-assistant home-assistant Bot added cla-signed dependency Pull requests marked as a dependency upgrade small-pr PRs with less than 30 lines. labels Feb 5, 2026
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the Python version from 3.14.2 to 3.14.3 across all CI workflows and bumps the base Docker image version from 2026.01.0 to 2026.02.0. The base image update includes libcec 7.1.1 and Python 3.14.3.

Changes:

  • Updated Python version from 3.14.2 to 3.14.3 in all GitHub Actions workflow files
  • Updated base Docker image version from 2026.01.0 to 2026.02.0 in the builder workflow

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
.github/workflows/wheels.yml Updated DEFAULT_PYTHON environment variable to 3.14.3
.github/workflows/translations.yml Updated DEFAULT_PYTHON environment variable to 3.14.3
.github/workflows/ci.yaml Updated DEFAULT_PYTHON and ALL_PYTHON_VERSIONS to 3.14.3
.github/workflows/builder.yml Updated DEFAULT_PYTHON to 3.14.3 and BASE_IMAGE_VERSION to 2026.02.0

Comment thread .github/workflows/builder.yml
@sairon sairon changed the title Bump base image to 2025.02.0 with Python 3.14.3, use 3.14.3 in CI Bump base image to 2026.02.0 with Python 3.14.3, use 3.14.3 in CI Feb 5, 2026
Copy link
Copy Markdown
Member

@frenck frenck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something seems to be off @sairon...

@home-assistant
Copy link
Copy Markdown
Contributor

home-assistant Bot commented Feb 5, 2026

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

@home-assistant home-assistant Bot marked this pull request as draft February 5, 2026 10:14
@sairon
Copy link
Copy Markdown
Member Author

sairon commented Feb 5, 2026

Majority of the test failures was caused by python/cpython#144506, as proven by the monkey-patch in the last commit. There are still quite some suspicious test failures, will look into them as well.

Comment thread homeassistant/core.py Outdated
@justanotherariel
Copy link
Copy Markdown
Member

Looking at the test logs in the CI pipeline, there are 49 integrations failing tests: backblaze_b2, bang_olufsen, cloud, comelit, config_entries, demo, devolo_home_network, dsmr, emulated_kasa, energyid, ghost, go2rtc, growatt_server, hdmi_cec, helpers, hydrawise, image_processing, izone, kitchen_sink, knx, local_file, mcp_server, media_player, numato, openai_conversation, otbr, ping, plex, pterodactyl, rflink, ring, satel_integra, shelly, sonos, stream, switch, switch_as_x, synology_dsm, template, tplink, trane, tuya, twinkly, unifi, update, valve, wake_on_lan, waterfurnace, wemo.

Also running these tests locally, I found a few more failures: entity_component, entity_platform, homee, litejet, lutron, openrgb, recorder, rfxtrx.

The few tests I have looked at seem geniune failures and Python versions <3.13.2 just hid those. We might have to go integration by integration to fix each.

So far, I have looked into two integrations:

Wemo (`wemo`)

Wemo fails a few tests, e.g.

FAILED tests/components/wemo/test_switch.py::test_available_after_update - AssertionError: assert 'off' == 'unavailable'

Looking at the wrapper:

    @contextlib.contextmanager
    def _wemo_call_wrapper(self, message: str) -> Generator[None]:
        """Wrap calls to the device that change its state.

        1. Takes care of making available=False when communications with the
           device fails.
        2. Ensures all entities sharing the same coordinator are aware of
           updates to the device state.
        """
        try:
            yield
        except ActionException as err:
            _LOGGER.warning("Could not %s for %s (%s)", message, self.name, err)
            self.coordinator.last_exception = err
            self.coordinator.last_update_success = False  # Used for self.available.
        finally:
            self.hass.add_job(self.coordinator.async_update_listeners)

It seems with the change in asyncio.futures._chain_future, if a test calls:

    await hass.services.async_call(
        domain,
        SERVICE_TURN_ON,
        {ATTR_ENTITY_ID: [wemo_entity.entity_id]},
        blocking=True,
    )
    assert hass.states.get(wemo_entity.entity_id).state == STATE_UNAVAILABLE

awaiting the service call doesn't guarantee that the entity has already changed, since the callback added to the event loop self.hass.add_job(self.coordinator.async_update_listeners) does not run after the coroutine anymore. It will instead run the next time the event loop processes its _ready queue. If we add a await hass.async_block_till_done() the test passes again. But I think the proper solution is to make sure that when the service call returns, the entities are all updated by rewriting the wrapper a bit.

Home Assistant Cloud (`cloud`)

The cloud integration tests (test_google_entity_registry_sync, test_do_not_create_repair_issues_at_startup_if_not_logged_in, test_create_repair_issues_at_startup_if_logged_in) fail with asyncio.exceptions.InvalidStateError: invalid state during test teardown on Python 3.14.3.

These tests set up the cloud component via mock_cloud(), which loads the cloud TTS platform. TTS depends on ffmpeg, so the ffmpeg component runs ffmpeg -version as a subprocess.

In theory, we have a session-scoped fixture prevent_ffmpeg_subprocess in tests/components/conftest.py that's supposed to mock this subprocess away, but its activation condition is find_spec("ffmpeg") is not None (#121628). This checks for a Python module named ffmpeg, which doesn't exist — the actual package is haffmpeg (installed as ha-ffmpeg). So the fixture was never active, and real ffmpeg subprocesses were always being spawned. -> This should be adressed in a seperate PR.

Why the test fails (creating a subprocess shouldn't be an issue - it just makes the test slow) is still not quite clear to me. The tracelogs point to asyncio/base_subprocess.py / _try_finish() so it might be a bug in cpython itself.

Copilot AI review requested due to automatic review settings April 28, 2026 09:22
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

@epenet
Copy link
Copy Markdown
Contributor

epenet commented Apr 29, 2026

CI now passes - but do we want this merged just before beta?
Or should we/could we jump straight to 3.14.4?

Please note that there might be some remaining flaky tests. The frequent ones have been exposed by all the test runs but there are probably some rarer ones lurking about.

@edenhaus
Copy link
Copy Markdown
Member

CI now passes - but do we want this merged just before beta? Or should we/could we jump straight to 3.14.4?

Discussed it with Frenck and it's okay from his side, if we create a nightly afterwards. I created a PR. Let's hope that the CI is not failing. Also I build a test image. If all looks fine, we can merge it and I will create a nightly afterwards, which I will test on the green

@sairon
Copy link
Copy Markdown
Member Author

sairon commented Apr 29, 2026

Closing in favor of #169444.

@sairon sairon closed this Apr 29, 2026
@github-actions github-actions Bot locked and limited conversation to collaborators Apr 30, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

cla-signed dependency Pull requests marked as a dependency upgrade small-pr PRs with less than 30 lines.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants