ci: bump workflows to Python v3.14 #2778

[kami922]

This PR updates the CI workflows to use Python 3.14 for testing.

Changes

• Update code_style and rule_linter jobs to use Python 3.14
• Update tests matrix to use Python 3.14 across all operating systems
• Add Python 3.13 to Ubuntu-specific test matrix (to ensure intermediate version coverage)
• Update binja-tests, ghidra-tests, idalib-tests to use Python 3.14

Fixes #2778

[gemini-code-assist]

Summary of Changes

Hello @kami922, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on modernizing the continuous integration (CI) environment by upgrading all relevant workflows and test matrices to Python 3.14. This ensures that the project remains compatible with the latest Python release, while also strategically including Python 3.13 in Ubuntu-specific tests to maintain broader version coverage and stability.

Highlights

• CI Workflow Updates: The code_style and rule_linter jobs have been updated to utilize Python 3.14.
• Test Matrix Enhancements: The tests matrix now uses Python 3.14 across all operating systems, with Python 3.13 specifically added to the Ubuntu test matrix for intermediate version coverage.
• Integration Tests: binja-tests, ghidra-tests, and idalib-tests have been updated to run with Python 3.14.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/tests.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the CI workflows to use Python 3.14, preparing the project for the upcoming Python release. The changes correctly modify the build, lint, and test workflows, and update the CHANGELOG.md. The logic of replacing Python 3.13 with 3.14 in the main test matrix while keeping a dedicated 3.13 run on Ubuntu is sound. I've added one suggestion to improve the readability of the test workflow configuration by keeping the included test versions sorted.

[kami922]

@mike-hunhoff @williballenthin @mr-tz Hello can you please rerun only the failed test

[mike-hunhoff]

Hmm it looks like the Ubuntu 3.14 arm tests are never finishing. I don't see a specific failure, but it's running for >60 minutes, so I'm guessing a timeout. Thoughts @williballenthin @mr-tz ?

[kami922]

Hello @mike-hunhoff @mr-tz I’m looking for some assistance regarding the current CI failures affecting my PRs. It appears that test_fix262 is failing consistently, and I wanted to check if this is a known issue on the main branch. Any advice on how to proceed would be appreciated.

[mr-tz]

See #2850

[mike-hunhoff]

@kami922 we're back to where we were before with the tests failing after hanging for an extended period of time, e.g. testing 3.14 failed after 22 minutes on Ubuntu and 76 minutes on Windows. I'm not seeing any errors listed in the corresponding CI workflows - have you been able to run tests locally without issue? I'm concerned there is an issue specific to 3.14 that causes capa to run poorly...

[mr-tz]

we should (mainly/also) bump https://github.com/mandiant/capa/blob/master/.github/workflows/build.yml (from Python 3.12 for the extra Linux build).

ref: #2594

[kami922]

@mike-hunhoff @mr-tz Hello so far i could not come up with any particular reason why are tests failing or operation being timed out,how ever windows tests are now passing they were failing earlier. I intend to investigate further but if you could please share any suggestion on where to look for the source for these discrepancies would be helpful.

[mr-tz]

I think this is probably a sign to hold off updating to 3.14. I'm not sure what the issues are but these all run for along time and eventually time out. I propose to close this for now and document in the associated issue.

[kami922]

hello all please give me 1-2 days more to work on it I think it might be related to github's version of arm version but i need to do more research. in the meantime i have 1-2 suggestions first is to increase time for Ubuntu other is to bypass vivisect tests for arm Ubuntu.

[kami922]

@mike-hunhoff @mr-tz @williballenthin Hello.
So i replicated the failing tests locally using docker and i stopped mid way becuase it already took 2hours + to execute and and i estimate another 2-3 hours to complete the run.
why did this occur.
Python 3.14 is ~4x slower on Linux ARM64 specifically

Python 3.14 changed internal CPython interpreter mechanics that perform poorly when compiled with GCC on Linux ARM64, making vivisect's CPU-heavy binary analysis ~4x slower, which pushes the total test time past what the GitHub runner can handle.

why does this not affect macos arm architecture is becuase macos uses clang while github's arm linux uses gcc.

[kami922]

@mike-hunhoff @mr-tz you may close this for now or we can skip tests for particular OS as it passes on other architectures.

[williballenthin]

Python 3.14 changed internal CPython interpreter mechanics that perform poorly when compiled with GCC on Linux ARM64, making vivisect's CPU-heavy binary analysis ~4x slower, which pushes the total test time past what the GitHub runner can handle.

would you please provide more explanation of this? it's an interesting explanation. how did you come to this conclusion?

[kami922]

@williballenthin @mike-hunhoff

1. python 3.14 introduced tail call interpreter which changes its execution system. Traditionally it used switch statement or "computed gotos" within a single giant function to dispatch bytecodes. now it splits each bytecode handler into separate C functions which use "jump" commands to reach subsequent handlers.

2. Clang advantage over GCC constitutes to 2 factors.
   musttai: It ensures the compiler performs a jump instead of a standard function call
   preserve_none: it is a particular calling method which works like GHC methods to inform the compiler that it should avoid register storage between brief functions.

GCC on AArch64 hardware does not support preserve_none while Clang 19+ on macOS proves to support this feature fully. The interpreter needs to handle register "shuffling" together with stack handling for each bytecode instruction that it processes.

3. Python 3.14 was release very recently,there are almost no pre compiled binary wheels for linux ARM64. The CI runner must compile every dependency from source (e.g., lxml, C-extensions),

ref:
https://lwn.net/Articles/1033373/
python/cpython#132138

I also guess it might be a know issue from here.
https://github.com/orgs/community/discussions/173431
actions/runner-images#9823