-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(ff): make site launch flag a bool flag #958
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does this play with migrated sites? ie when is the git clone step for these sites going to occur ah?
there's a form for prod ops to fill up that triggers a clone |
@seaerchin wait so to be clear, post email migration of sites there needs to a manual sending submission of this form by eng/ops? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non blocking nits
d18a23f
to
7880953
Compare
* refactor(formsg-site-clone): remove and add to site creation (#971) * refactor(formsg-site-clone): remove and add to site creation * fix(formsgsitecreation): fixed rename betrayal by vvscode * refactor(formsgsitecreation): cloen only on email * refactor(ff): make site launch flag a bool flag (#958) * refactor(ff): make flag a bool flag * refactor(flags): update ff * refactor(reposervice): remove function * refactor(routehandler): remove function * fix(routehandler): rename ff * fix(reposervice): update test spec * Feat/quickie/site-create-form (#985) * feat(git clone): add branch * feat(db): update deployments table * fix(reposService): fix git commands * fix(reposService): cleaner code * fix(tests): fix failing tests * style(deploymentService): better error messages * chore(auth): upgrade auth redirect endpoint to use v2 (#986) * 0.50.0 --------- Co-authored-by: Kishore <[email protected]> Co-authored-by: seaerchin <[email protected]>
Problem
Right now, our GGS flag adopts a two tiered approach - first, we get the list of repos from growthbook then we validate based on that.
This is a whitelist approach, where we add sites as they shift to ggs. This is effortful and going forward, we want to make our flag a blacklist approach, where we allow sites by default until we need to blacklist them.
Solution
Add new flag on growthbook that returns a boolean value checking if the user type is email and whether site is blacklisted. (it's true if user is email && site isn't blacklisted)
Deploy notes
these steps have to be done pre deploy
these steps have to be done post deploy
is_ggs_enabled
on production