feat: migration from 2.2 -> 3.2 -> 4.2 #2520
Conversation
|
Quite a bit less migrations after changing from BigAuto to just Auto! :) |
note: unsure if "valid"
Co-authored-by: Ezio Melotti <[email protected]>
…TION ACCOUNT_PREVENT_ENUMERATION was introduced in django-allauth 0.52.0, and interferes with our expectations. This should probably be turned on! But for now disable it by default to keep the changeset minimal. Allauth _used_ to iterate over users to check for email uniquenss but stopped at some point, so we have to create an EmailAdress object for the user in the relevant test-case for duplicate emails
|
Whats the path to standing this up as staging.python.org @ewdurbin ? |
|
staging was retired years ago for numerous reasons, but the main one being that representative data for most features wasn't present there... so it was ultimately only valuable for previewing frontend changes. we would need to create a new deployment from scratch at this point, and populate it with some representative data. |
|
@ewdurbin Is it a big ask to have prod data load periodically into staging to keep it fresh? OR atleast lightweight fixture data that has things we test frequently? |
|
I'm a pretty massive -1 on prod -> staging copy concept. There are a lot of side-effects that could occur to send email or update information that would be hard to keep track of. Aside from that there's just the duplication of private information. If a reasonable set of fixtures existed (sufficient for local development/testing) that would be a splendid base for a staging environment though, and I'd be +1 to that. |
psf-cabotage-us-east-2
bot
temporarily deployed
to
staging.python.org
What
Closes