build: use pinned Django version for tests - #29890
Conversation
|
@BbrSofiane @cmltaWt0 FYI |
|
BTW, if we like the logic here, we can solve the 4.0 problem just by commenting out that part of the Django version matrix. |
bb3d017 to
1ced12c
Compare
|
Oh, also looks like "django-3.2" tests are required, but will no longer exist after this change, so that has to be adjusted as well. |
|
doing |
|
doing |
I'm not sure what you are suggesting? This would be instead of using django.txt ever? I'm concerned about having two different mechanisms for installing Django: in production, we use the specific version pinned in requirements/edx/django.txt. In tests we wouldn't. That seems like a bad idea. This issue came up because the pin on the Maple branch was mistakenly changed to a non-existent Django version. The tests passed. The code would have failed in production. I'm trying to ensure that the tests accurately test the code as it will run in production. |
1ced12c to
349b2ce
Compare
349b2ce to
0582eb9
Compare
UsamaSadiq
left a comment
There was a problem hiding this comment.
I've tested on local as well. The recommended approach works fine and I believe we can go ahead and upgrade this change.
For the required checks, we'll need to mark the new tests as required from the repo settings.
The logic here seems to work, but Django 4.0 won't install over our other pinned requirements, so tests fail for Django 4.0.
0582eb9 to
99038b2
Compare
|
We'll need to remove the old tests marked as required from the repo settings and mark the new tests as required to merge this PR. |
|
I've removed the django-3.2 required checks, and will enable the -pinned checks once merged. |
|
EdX Release Notice: This PR has been deployed to the staging environment in preparation for a release to production. |
|
EdX Release Notice: This PR has been deployed to the production environment. |
The existing method of installing Django will continue to use 3.2.11 even though 3.2.12 is available. We ran into this on the maple.master branch when we upgraded the pin to 3.2.12, and saw that the tests were still using 3.2.11
I've tried to accommodate both "master" and "upgrading" workflows here with the Django matrix, but maybe there is a better way? Installing "Django==~4.0.0" won't work now because it conflicts with too many of our other requirements.
Note: I've made one change to the action just for temporary testing of this pull request.