Conversation
annehaley
left a comment
There was a problem hiding this comment.
We ran into the same problem on ShapeWorks, another Girder 4 project.
Our first attempt had been to do this exact thing: MedVIC-Lab/shapeworks-cloud#339. It looked like it had worked, but it was only behaving properly in our CI; all our deployed instances were broken with this change.
Instead, we ended up reverting that change and pinning django-allauth for the time being (at least until this is fixed upstream): MedVIC-Lab/shapeworks-cloud#341.
If you look at the tests, the first PR is all green, so we thought it would work. But then the tests on master failed after merging because our deployed version was broken (and one of our tests tries to communicate with the deployed version).
So David put in the second PR, which looks red because at that point the deployed version was still down. But after merging the second PR, our tests on master all passed and our deployed version was working again.
We don't have a deployment for this project (or tests even), so I don't know if we would ever have this problem. But pinning the version was what worked best on that other project, so it's worth considering. I am open to using either solution on this project since we're only affecting our own dev versions.
|
I'm okay with version pinning. If you have a working local image without this issue, what version of allauth is installed? |
|
My container is currently using |
|
Thanks for the advice! Closing in favor of #29. |
After rebuilding my docker image, I'm getting incessant errors about this allauth middleware setting, which prevent Django from running in any capacity.
@annehaley I'm curious to see if this works for you without issue on an existing (not recently rebuilt) local image.