task: changing variants blocked by cr #2966
Conversation
This PR adds two new functions that is protected by CR. When used instead of the current setVariantOnEnv and setVariantsOnEnv if the flag UNLEASH_EXPERIMENTAL_CR_ON_VARIANTS is set, the call is blocked. This leaves the old functions, which is used from the CR flow in place, and adds new methods protected by CR.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
|
Tbh, this could be a unit test as well with mocker objects, but I'd still like to have the e2e tests for this considering this could break a major workflow if it doesn't work. I can add a unit test with mockstores as well. What do you think? |
| for (const env of environments) { | ||
| await this.stopWhenChangeRequestsEnabled(projectId, env); | ||
| } | ||
| } |
There was a problem hiding this comment.
I'm thinking if we're missing something here... imagining we have CR enabled in some environment and we're trying to push certain variants configuration to all environments. This would require you to know which envs have change request and which don't...
Perhaps this is something for the UI to split the Push into 2 sets, one for the CR endpoint another for the variants endpoint... Not convinced about this idea either
There was a problem hiding this comment.
Also, I think it would be nice to have a method that accepts all envs here, so we don't need to do n queries.
About the changes
This PR adds two new functions that is protected by CR. When used instead of the current setVariantOnEnv and setVariantsOnEnv if the flag UNLEASH_EXPERIMENTAL_CR_ON_VARIANTS is set, the call is blocked. This leaves the old functions, which is used from the CR flow in place, and adds new methods protected by CR.
Also adds e2e tests verifying that the methods will block requests if CR is enabled for project:environment pair, as well as not block if CR is not enabled. Tests already in place should confirm that the default flow, without the flag enabled just works.