[ci] Added Django 6.0 to CI test matrix#199
Conversation
📝 WalkthroughWalkthroughUpdates to add and verify compatibility with newer Django versions: CI now tests Django 6.0, requirements expand Django upper bound to <6.1 and point openwisp-utils to master. README compatibility tables updated (Python 3.9+ entry and multiple Django compatibility rows). Tests in admin and admin inline were relaxed to check for geometry/image content text rather than specific HTML widget structure. ReadOnlyMixin now disables form fields (field.disabled = True) and sets widget.read_only = True for view-only handling, with expanded docstring describing Django 6.0+ behavior. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 1 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
🔇 Additional comments (2)
✏️ Tip: You can disable this entire section by setting Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci.yml (1)
35-41: Add matrix exclusions for unsupported Python versions with Django 6.0.Django 6.0 supports Python 3.12, 3.13, and 3.14. This release also drops support for Python 3.10 and 3.11, requiring Python 3.12 or higher.
The current matrix includes Python 3.10 and 3.11, but Django 6.0 doesn't support these versions. Without exclusions, those CI jobs will fail during installation or test execution.
🔧 Proposed fix to add exclusions
exclude: # Python 3.13 supported only in Django >=5.1.3 - python-version: "3.13" django-version: django~=4.2.0 - python-version: "3.13" django-version: django~=5.0.0 + # Python 3.10 and 3.11 are not supported in Django 6.0 + - python-version: "3.10" + django-version: django~=6.0.0 + - python-version: "3.11" + django-version: django~=6.0.0
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/ci.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (15)
- GitHub Check: Python==3.12 | django~=5.2.0
- GitHub Check: Python==3.13 | django~=5.1.0
- GitHub Check: Python==3.12 | django~=6.0.0
- GitHub Check: Python==3.11 | django~=5.0.0
- GitHub Check: Python==3.13 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=5.1.0
- GitHub Check: Python==3.12 | django~=4.2.0
- GitHub Check: Python==3.10 | django~=4.2.0
- GitHub Check: Python==3.12 | django~=5.0.0
- GitHub Check: Python==3.11 | django~=4.2.0
- GitHub Check: Python==3.12 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=5.1.0
- GitHub Check: Python==3.11 | django~=5.2.0
- GitHub Check: Python==3.10 | django~=5.0.0
- GitHub Check: Python==3.10 | django~=5.2.0
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
- Remove expectation of img tag for floorplan images in readonly mode - Remove expectation of geometry map div in readonly location views - Update floorplan image assertion to use name instead of url for object locations
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@README.rst`:
- Around line 66-70: The Python compatibility table in README.rst has duplicate
version key "1.1" with conflicting requirements; update the second "1.1" entry
(the line showing ">=3.9") to the correct version (e.g., "1.2") so each version
key is unique and matches its intended Python requirement, ensuring the table
rows read "1.0 >=3.7", "1.1 >=3.8", "1.2 >=3.9", "dev >=3.10" (or the correct
version label your project uses).
🧹 Nitpick comments (2)
requirements.txt (1)
5-5: Same concern: pinning tomasterbranch.As noted in
requirements-test.txt, using the master branch creates reproducibility issues. This should be updated to a tagged release once openwisp-utils publishes Django 6.0 support.requirements-test.txt (1)
3-3: Pinning tomasterbranch introduces CI instability risk.Using the
masterbranch tarball means CI builds may break unexpectedly when upstream changes are pushed. The latest stable release (v1.2, Oct 2025) does not support Django 6.0, which explains themasterbranch dependency. Once OpenWISP releases a stable version with Django 6.0 support, pin to that version.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
README.rstdjango_loci/tests/base/test_admin.pydjango_loci/tests/base/test_admin_inline.pyrequirements-test.txtrequirements.txt
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (16)
- GitHub Check: Python==3.13 | django~=5.1.0
- GitHub Check: Python==3.13 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=4.2.0
- GitHub Check: Python==3.11 | django~=5.0.0
- GitHub Check: Python==3.11 | django~=5.1.0
- GitHub Check: Python==3.13 | django~=6.0.0
- GitHub Check: Python==3.12 | django~=6.0.0
- GitHub Check: Python==3.12 | django~=5.1.0
- GitHub Check: Python==3.10 | django~=5.2.0
- GitHub Check: Python==3.11 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=5.0.0
- GitHub Check: Python==3.12 | django~=5.2.0
- GitHub Check: Python==3.12 | django~=4.2.0
- GitHub Check: Python==3.10 | django~=4.2.0
- GitHub Check: Python==3.10 | django~=5.0.0
- GitHub Check: Python==3.10 | django~=5.1.0
🔇 Additional comments (4)
README.rst (1)
72-78: LGTM!The Django version compatibility table is well-structured and correctly documents the supported Django versions for each release.
django_loci/tests/base/test_admin.py (1)
244-245: LGTM - appropriate relaxation for Django 6.0 compatibility.The assertion now checks for the presence of the image URL rather than a specific
<img>tag structure. This accommodates Django 6.0's readonly field rendering changes while still validating that the image URL is present in the response.django_loci/tests/base/test_admin_inline.py (1)
903-908: Inconsistent image assertion between readonly tests.This test uses
fl.image.name(line 908), whiletest_readonly_indoor_location(line 883) usesfl.image.url. These properties return different values:
.name: relative path (e.g.,floorplans/test.png).url: full URL path (e.g.,/media/floorplans/test.png)Is this inconsistency intentional due to different rendering contexts in Django 6.0, or should both tests use the same property?
requirements.txt (1)
1-1: Version constraint is appropriate. Django 6.0 was released stably on December 3, 2025, making the<6.1.0upper bound suitable for Django 6.0 support.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| 1.0 >=3.7 | ||
| 1.1 >=3.8 | ||
| 1.1 >=3.9 | ||
| dev >=3.10 | ||
| =========== ============== |
There was a problem hiding this comment.
Duplicate version entry in Python compatibility table.
There are two entries for version 1.1 with different Python requirements (>=3.8 on line 67 and >=3.9 on line 68). This appears to be an error—one of these should likely be a different version number (e.g., 1.2).
Suggested fix
=========== ==============
django-loci Python version
1.0 >=3.7
-1.1 >=3.8
-1.1 >=3.9
+1.1 >=3.8
+1.2 >=3.9
dev >=3.10
=========== ==============🤖 Prompt for AI Agents
In `@README.rst` around lines 66 - 70, The Python compatibility table in
README.rst has duplicate version key "1.1" with conflicting requirements; update
the second "1.1" entry (the line showing ">=3.9") to the correct version (e.g.,
"1.2") so each version key is unique and matches its intended Python
requirement, ensuring the table rows read "1.0 >=3.7", "1.1 >=3.8", "1.2 >=3.9",
"dev >=3.10" (or the correct version label your project uses).
Django 6.0 no longer renders widgets for readonly fields. Instead, readonly fields display the plain text value of the field. - Remove assertions checking for 'geometry-div-map' widget in readonly views - Remove assertions checking for 'id_indoor_map' widget in readonly views - Add assertion to verify geometry value is displayed as text - Update comment to explain Django 6.0 behavior change
db9e722 to
d1cc0e1
Compare
Django 6.0 changed how readonly fields are handled in the admin. Setting read_only=True on a widget no longer renders the widget - instead it shows only plain text values. The recommended approach for Django 6.0+ is to disable the field instead of marking it readonly. This allows the widget to render fully while preventing editing, giving readonly users an interactive but non-editable view of the field (e.g., a functional but non-interactive map). Changes: - Modify ReadOnlyMixin.set_readonly_attribute() to use field.disabled=True - Keep read_only attribute on widget for backwards compatibility - Add explanatory comments about Django 6.0 behavior change - All 58 tests pass including readonly field tests This preserves the intended UX where view-only users can see interactive map widgets while being prevented from making changes.
Checklist