This fixes Char32UUIDField implementation in 5.0 release notes causing
records with UUIDFields created using pre-Django 5.0 and CHAR(32) not
being able to be saved anymore after upgrading and keeping the CHAR(32)
columns.
Regression in 7cd187a5ba.
The original event trigger pull_request_target runs against the target branch (main), not the branch associated with the PR. Consequently, any new screenshots added in a PR are not captured, and the available screenshots reflect the state of the main branch code, not the code from the PR's branch.
This update addresses the issue by changing the event trigger to pull_request. However, it's important to note that this adjustment breaks the comments functionality since the action no longer has write permissions.
GEOIP_SETTINGS is removed from the global scope as this prevents
modifications to the settings using @override_settings in tests.
Additional improvements now that we have stable test databases include:
- Made testing more comprehensive and improved coverage
- Patched socket.gethostbyname() for whole test case
- Added testing of non-free GeoIP2 databases
Co-authored-by: Tom Forbes <tom@tomforb.es>
Regression in d9de74141e.
This is a long standing issue, however it caused a crash of
GeneratedFields for all output fields that have backend-specific
converters when the RETURNING clause is not supported
(MySQL and SQLite < 3.35).
That's why severity was exacerbated.
The implementation of some core types differ between CPython and PyPy
and this may affect the way that pickling works such that errors are
raised in differing locations in the interpreter or not at all.
Use our own custom non-pickleable type instead to avoid these quirks.
Depending on screen sizes, the selenium tests that would "click" or interact
with an element outside the scope of the visible window would produce test
failures (raising ElementNotInteractableException in CI runs).
This branch switches those to using ActionChains, which ensures that the click
(or other interaction) is performed only after successfully completing the
move to the relevant element.
Co-authored-by: Tom Carrick <tom@carrick.eu>
This test relied on the behavior of subclassing `datetime.timezone`
which is not permitted by the C-extension version of CPython's
`datetime` module. This restriction isn't enforced by the pure
Python version, nor by PyPy.
See https://github.com/python/cpython/issues/112451
It's not critical, and doesn't test any Django behavior, so just
remove it.