woocommerce/plugins/woocommerce-blocks/.wp-env.json

36 lines
1.3 KiB
JSON
Raw Normal View History

Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
{
"core": "https://wordpress.org/wordpress-latest.zip",
"phpVersion": "7.4",
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
"plugins": [
"https://github.com/WP-API/Basic-Auth/archive/master.zip",
"https://downloads.wordpress.org/plugin/wordpress-importer.0.8.zip",
"./tests/mocks/woo-test-helper",
"../woocommerce"
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
],
"env": {
"tests": {
"mappings": {
"wp-cli.yml": "./wp-cli.yml",
"wp-content/mu-plugins": "./node_modules/@wordpress/e2e-tests/mu-plugins",
"wp-content/plugins/gutenberg-test-plugins": "./node_modules/@wordpress/e2e-tests/plugins",
"wp-content/plugins/woocommerce-blocks-test-plugins": "./tests/e2e/plugins",
"wp-content/plugins/woocommerce/blocks-bin": "./bin",
"wp-content/plugins/woocommerce/blocks-bin/playwright": "./tests/e2e/bin",
"wp-content/themes": "./tests/e2e/themes",
"wp-content/themes/storefront": "https://downloads.wordpress.org/theme/storefront.latest-stable.zip",
"wp-content/themes/twentytwentyfour": "https://downloads.wordpress.org/theme/twentytwentyfour.latest-stable.zip"
}
}
},
"config": {
Create GitHub actions for automated tests (https://github.com/woocommerce/woocommerce-blocks/pull/3544) * Create end-to-end-tests.yml for E2E testing action * Change actions to run on push instead of PR * Install libstdc++-4.9-dev on E2E tests action * Add correct apt repository for libstc++ * Reconfigure apt-get commands for installing libstdc++ * Remove accidental inclusion of Travis config from E2E tests action * Install libkrb5-dev as part of e2e test action * Run apt commands as sudo * Install gutenberg plugin and e2e testutils * Add environment variables to E2E tests * Rename action and add further config for composer and wp-env * Rename workflow * Add jobs for WP 5.6, 5.5, and 5.4 * Fix YML indentation * Apply 767 permissions to wp-env directory * Run chmod as sudo * Comment 5.6 and 5.6 with GB out to test 5.4 more easily * Remove WP install job, since it should run on each step * Change order of wp-env start and chmod * Reorder commands for 5.4 job * Try running 5.4 tests in isolation * Reenable tests for all WP versions * Move commands out of bash script into a series of commands * Fix indentation on 5.5 job * Re-enable libkrb5-dev install * Clean wp-env before each run & upgrade wp-env to 3.0.0 * Update lock file for wp-env@3.0.0 * Reorder wp-env start and clean commands * Reorder wp-env permissions commands * Reorder wp-env permissions setup for all jobs * Reorder wp-env permissions setup for 5.5 and 5.4 * Ensure correct order for env setup and flush permalinks twice * Update jest snapshots * Remove rewrite flush command from yml * Remove npm build from every step and try it just at the start * Set correct e2e build script * Add jobs for PHP 8 * Specify PHP 8 minor version * Run PHP 8 jobs first * Remove PHP 8 jobs * Add JS Unit tests job * Remove js-unit-tests.js workflow * Remove composer install from every step, add it to its own step * Cache composer files * Bust npm cache to test nodegit * Rename npm cache * Renove npm cache entirely * Revert "Renove npm cache entirely" This reverts commit d6fac6a6ebd9162e48f64daaa8c971320756579e. * Rename npm cache back to how it was * Fix yml indentation * Remove echo from composer cache step * Revert back to composer example * Add PHP Unit tests to workflow * Add PHP Unit tests to workflow * Rename E2E tests workflow and file * deliberately break e2e and unit tests to test workflow 👺 * fix php test, should see e2e fail * revert broken e2e test * Change steps into jobs, rename workflow * Remove Travis workflow file * Add all necessary setup steps to each job * Rename Setup job and remove dependency * Add individual jobs for each E2E test environment * Add npm install and build to setup job * YML syntax fix * Remove error-causing chmod * Rename blocks.ini setup step Fixes a typographical error. * Get the latest stable version of WooCommerce for PHPUnit testing * Add PHP8.0 and PHP5.6 Unit tests * Run composer update for PHP 5.6 and PHP 8.0 * Revert "Run composer update for PHP 5.6 and PHP 8.0" This reverts commit 4f90522d0b52b7a8b9e896e9c783795be9dc5399. * Revert "Add PHP8.0 and PHP5.6 Unit tests" This reverts commit 66e317dec4af6e3a2ac6f78b6efd050e7fc5aa8e. Co-authored-by: Rua Haszard <rua.haszard@automattic.com>
2021-01-05 09:27:22 +00:00
"JETPACK_AUTOLOAD_DEV": true,
Add migration strategy and load blockified templates (https://github.com/woocommerce/woocommerce-blocks/pull/6538) * Increase `schema_version` to add the new `wc_blocks_use_blockified_templates` flag If the schema version stored on the db is <= 260 means the plugin is being updated to the new version and we should keep using the old templates, not the blockified ones. * After the theme is switched we check if we need to update the flag to start loading the blockified templates or not. * Get the templates from the blockified folder if the flag is set to true on the db * Add temporary blockified template for testing purposes * Inline variable * Improve comment * Use blockified templates on new installs with block themes only * Don't use blockified templates when switching to a non FSE theme * Fix condition * Add tests for the option value * Move the check to use blockified templates * WIP * WIP * Add migration strategy * Move the blockified templates to the templates folder and filter them depending on the option * Fix tests and start using the Options constants * Fix migration, the `should_use_blockified_product_grid_templates` and tests * Rename tests and move to Utils folder * add Migration class test * try * remove PHP * add composer * Replace the blockified templates with a temporary version * Fix tests * add comment * Add feature gating for experimental builds * Inject the package to the controller * test * Change blocks.ini * debug * Remove debug info * fix test * fix tests * try now * using composer cache * install deps * test * Remove unnecessary extra key * Add cache actions * Undo tests change * Fix readme format Co-authored-by: Luigi <gigitux@gmail.com>
2022-07-06 07:51:39 +00:00
"SCRIPT_DEBUG": false,
"WP_TESTS_DOMAIN": "http://localhost:8889",
"WP_TESTS_EMAIL": "admin@example.org",
"WP_TESTS_TITLE": "Test Blog",
Add PHP8 Unit Testing (https://github.com/woocommerce/woocommerce-blocks/pull/7528) * fixed method sig * Updated to @wordpress/env@5.5.0 and set default PHP 7.4 for wp-env. * updated Coding Standards flow to use PHP 8.0 * Added comment to E2E flows explaining what PHP version is used * Revert "Updated to @wordpress/env@5.5.0 and set default PHP 7.4 for wp-env." This reverts commit 696cd7f42edc9d9726b777cf4f83a501a6d63936. * Added comment to Unit test flows explaining what PHP version is used. Specified PHP version on .wp-env.json * Fixed composer-lock.json version. * Updated tests to run on PHP Unit 9.2.6 * Updated tests to run on PHP 8 * Reverted test, mismatched results between local and pipeline * Removed Todo * Updated platform overrides * Update Migrationb tests with Mockery for PHP8 compat * try at PHP unit flow matrix * Fix blocks.ini invalid config * Temp disable E2E * Downgraded woocommerce/woocommerce-sniffs as it introduced new sniffs we should be handling on a different PR * re-enable E2E tests * blocks.ini fix * revert blocks.ini fix * Update @wordpress/env * remove .htaccess mapping * Fix permissions for tests * Debug permissions * Attempt at perm fix * Attempt at perm fix * Downgraded @wordpress/env * Another attempt at upgrade @wordpress/env * Attempt at cleaning wp-env before run * Attempt at destroying wp-env before run. Disabled E2E. * Attempt at destroying wp-env before run. * debug wp-env data * attempt at deleting wp-env data (destroy won't work due to prompt) * re-enable E2E * Fix deprecation warnings * Cleaned wp-env data for E2E * Fix perms for E2E * Updated RateLimitsTests * debug * Force 7.4 for wp-env * Run sh outside of npm * Reverted E2E flow * reverted wp-env-config.sh debug test * reverted .wp-env.json phpVersion force * Update tests/php/StoreApi/Utilities/ProductQueryFilters.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/CartExtensions.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/CartItems.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/Products.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/ProductCollectionData.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/Batch.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/Checkout.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/CartCoupons.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/ProductAttributes.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Update tests/php/StoreApi/Routes/Cart.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * downgraded @wordpress/env to v4 * Reverted back to reflection class for pivate attribs manipulation on tests * reverted JS unit testing job name * Update tests/php/StoreApi/Formatters/TestMoneyFormatter.php Co-authored-by: Mike Jolley <mike.jolley@me.com> * Typo fix Co-authored-by: Mike Jolley <mike.jolley@me.com>
2022-11-09 15:28:08 +00:00
"WP_PHP_BINARY": "php",
"WP_TESTS_DIR": "./tests/php",
"WP_PHPUNIT__TESTS_CONFIG": "./vendor/wp-phpunit/wp-phpunit/wp-tests-config.php"
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
}
}