-
Notifications
You must be signed in to change notification settings - Fork 103
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
VIP Integrations: Improves reading of config files and add multiple configs support of same integration #5643
base: develop
Are you sure you want to change the base?
Conversation
…s-to-read-files-in-generic-way
…s-to-read-files-in-generic-way
…ig methods which are moved
dcd3c2d
to
13fdecc
Compare
…s-to-read-files-in-generic-way
…s_based_on_vip_configs
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5643 +/- ##
=============================================
+ Coverage 29.53% 29.60% +0.06%
- Complexity 4779 4792 +13
=============================================
Files 282 282
Lines 20597 20608 +11
=============================================
+ Hits 6083 6100 +17
+ Misses 14514 14508 -6 ☔ View full report in Codecov by Sentry. |
4377568
to
c5586c6
Compare
c5586c6
to
4653616
Compare
…s-to-read-files-in-generic-way
* | ||
* @return array<Env_Integration_Status> | ||
*/ | ||
private function get_site_statuses() { |
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.
Method moved from IntegrationVipConfig
file and added multi status support.
public function set_vip_config( IntegrationVipConfig $vip_config ): void { | ||
if ( ! $this->is_active() ) { | ||
trigger_error( sprintf( 'Configuration info can only assigned if integration is active.' ), E_USER_WARNING ); // phpcs:ignore WordPress.PHP.DevelopmentFunctions.error_log_trigger_error | ||
public function get_site_configs() { |
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.
Method moved from IntegrationVipConfig
file and added multi configs support.
* @return void | ||
*/ | ||
public function activate_platform_integrations() { | ||
public function activate_platform_integrations( VipIntegrationsConfig $vip_integrations_config ) { |
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.
For easier mocking providing config as a param.
|
||
return false; | ||
}, E_USER_WARNING ); | ||
$this->original_error_reporting = setup_custom_error_reporting(); |
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.
Avoided duplication across files and added following methods:
- setup_custom_error_reporting
- reset_custom_error_reporting
@@ -147,19 +141,435 @@ public function test__is_active_returns_false_when_integration_is_not_active(): | |||
$this->assertFalse( $integration->is_active() ); | |||
} | |||
|
|||
public function test__set_vip_config_function_throws_error_if_integration_is_not_active(): void { | |||
public function test__is_active_via_vip_returns_false_if_empty_config_is_provided(): void { |
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.
- Moved methods from
test-integration-config.php
class to here. - Updated methods to allow multiple configs.
…s-to-read-files-in-generic-way
Quality Gate passedIssues Measures |
Pausing on this for now. Will revisit when we're adding in this functionality. |
Had some discussions with Cantina team and we decided to reopen this Pull Request while keeping the existing proposal as is. |
…s-to-read-files-in-generic-way
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.
- Changed the name to vip-integrations-config.php and refactored the code.
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.
- Changed the name from
integration-vip-config.php
- Refactored
get_vip_config_from_file
to read all files at once and rename the function toread_config_files
- Moved
is_active_via_vip
,get_site_status
,get_site_config
andget_value_from_config
toIntegration
class because it makes more sense there. Apart from this added support for multiple configs.
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.
FakeMultiConfigIntegration
class for multi config integration.
* @private | ||
*/ | ||
public function is_active_via_vip(): bool { | ||
return in_array( Env_Integration_Status::ENABLED, $this->get_site_statuses() ); |
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.
For multiple setups enable the integration if any of the source is ENABLED
.
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.
I still think we absolutely need the concept of a parent integration present here. The parent should be the one deciding if the whole thing should be enabled (and at what version) for the env/subsite.
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.
/** | ||
* Setup custom error handler and returns current level of error reporting. | ||
*/ | ||
function setup_custom_error_reporting(): int { |
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.
Moved duplicated code to following methods
- setup_custom_error_reporting
- reset_custom_error_reporting
Made some minor changes and now this PR is good for review. |
@@ -7,7 +7,8 @@ | |||
|
|||
namespace Automattic\VIP\Integrations; | |||
|
|||
use Automattic\VIP\Integrations\IntegrationVipConfig; | |||
use Org_Integration_Status; |
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.
I believe we're actually moving away from differing the statuses and want it all in one.
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.
yes please, let's normalize and just have one "statuses" enum.
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.
As of now we don't support all statuses on ORG
and ENV
so I think the distinction makes sense and explaining the code.
if ( ! $this->is_active() ) { | ||
trigger_error( sprintf( 'Configuration info can only assigned if integration is active.' ), E_USER_WARNING ); // phpcs:ignore WordPress.PHP.DevelopmentFunctions.error_log_trigger_error | ||
public function set_vip_configs( array $vip_configs ): void { | ||
$this->vip_configs = $vip_configs; |
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 come we're removing the active check?
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.
We are only using set_vip_configs in one place which is already handling the is_active case, therefore removed it.
} | ||
|
||
// Return config object if integration have only one config else return all configs. | ||
return ( ! $this->have_multiple_setups && isset( $configs[0] ) ) ? $configs[0] : $configs; |
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.
Besides Composable, how many other integrations will have multiple set-ups? Just wondering, but is this something that can be handled elsewhere? :/
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.
There are some nice benefits to having individual sources be able to cascade down with their own configs like the other integrations. Helps prevent duplication for network sites for example, and keeps things logically operating the same way.
@@ -7,7 +7,8 @@ | |||
|
|||
namespace Automattic\VIP\Integrations; | |||
|
|||
use Automattic\VIP\Integrations\IntegrationVipConfig; | |||
use Org_Integration_Status; |
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.
yes please, let's normalize and just have one "statuses" enum.
if ( $this->get_value_from_config( $vip_config, 'org', 'status' ) === Org_Integration_Status::BLOCKED ) { | ||
return [ Org_Integration_Status::BLOCKED ]; | ||
} |
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.
Can we instead make these decisions in goop before setting the configmap?
Anything that doesn't belong on a site config (based on inheritance from the client level) shouldn't end up in the configmap in the first place.
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.
-
Currently we can get the info about why a particular integration doesn't have any data in ConfigMap by just looking at the file. If we move it to GOOP then we loses this visibility which effect debugging if user doesn't have enough permissions.
-
In future we can have integrations that want to show some notification in WP Dashboard if the plugin is
blocked
on client level. So it's useful to have this info available.
If we decide on making any change then I will make these changes in the next PR because this PR is just doing refactoring.
* 'parsely' => array( | ||
* array( | ||
* 'org' => array( 'status' => 'blocked' ), | ||
* 'env' => array( | ||
* 'status' => 'enabled', | ||
* 'config' => array(), | ||
* ), | ||
* 'network_sites' => array ( | ||
* 1 => array ( | ||
* 'status' => 'disabled', | ||
* 'config' => array(), | ||
* ), | ||
* 2 => array ( | ||
* 'status' => 'enabled', | ||
* 'config' => array(), | ||
* ), |
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.
I know it's just an example, but I think this is surfacing in the code as a result so wanted to point out here too.
Nothing blocked at the org level should ever make it to the WP site. There's no scenario where we will block on org but enable on env. If blocked at org level or site level, then that should mean the configmap will never see an entry for that integration. It doesn't exist at all.
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.
Thanks for pointing this out. Fixed the example in fe14e06
As per current implementation if the integration is blocked on org
level then we don't include any data from site level integration even if there is data.
// Example
<?php
return array(
'parsely' => array(
array(
'org' => array( 'status' => 'blocked' ),
),
),
);
// Look for key inside org or env config. | ||
if ( 'network_sites' !== $config_type && isset( $vip_config[ $config_type ][ $key ] ) ) { | ||
return $vip_config[ $config_type ][ $key ]; | ||
} |
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.
I'm not even sure if we need to concept of org configs down at this level either.
When generating configmaps, we're already dealing with only one specific environment. So we can decide what the configs are for that particular environment (based on higher levels if needed), and pass down the resulting env configs along with network site configs if it's a MS.
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.
Currently from code point of view we do support having config on org
level but in actual we don't have any config from ConfigMap
so feel free to let me know if you like me to add a condition here which throws the error if config is provided on org
level. Personally I think it is fine as it is.
} | ||
|
||
// Return config object if integration have only one config else return all configs. | ||
return ( ! $this->have_multiple_setups && isset( $configs[0] ) ) ? $configs[0] : $configs; |
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.
There are some nice benefits to having individual sources be able to cascade down with their own configs like the other integrations. Helps prevent duplication for network sites for example, and keeps things logically operating the same way.
* @private | ||
*/ | ||
public function is_active_via_vip(): bool { | ||
return in_array( Env_Integration_Status::ENABLED, $this->get_site_statuses() ); |
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.
I still think we absolutely need the concept of a parent integration present here. The parent should be the one deciding if the whole thing should be enabled (and at what version) for the env/subsite.
Quality Gate passedIssues Measures |
Description
Changelog Description
Improved VIP Integrations
Pre-review checklist
Pre-deploy checklist
type
attribute. We do have this reload ability available in backend API.Steps to Test
Checkout this PR
Run the vip site locally using
vip dev-env start --slug [YOUR_SLUG]
(if no env is available then create it)Create integration config files inside
php
container and place configs (we have to do it manually because as of nowvip dev-env
doesn't have support to auto create this folder/file while creating new envs)docker exec -it [CONTAINER_NAME] /bin/sh
mkdir /wp/config/integrations-config
touch /wp/config/integrations-config/parsely-config.php
and adds following contentparsely
can be replaced with any other slug of the integrationCreate config files for multiple integrations.
touch /wp/config/integrations-config/[SLUG]-123-config.php
and adds following contenttouch /wp/config/integrations-config/[SLUG]-456-config.php
and adds following contentRestart vip dev-env to apply changes in these config files.
Verify integration enablement with different combinations of vip configs e.g.
wp-parsely
plugin is activated with the SiteID and secrets which are provided by VIP (credentails support will be available onv3.9
and above).Apart from enabling the plugin via VIP config, customer can also enables it by placing
\Automattic\VIP\Integrations\activate( 'parsely' );
inplugin-loader.php
file so better to also test this flow also.