Steve-Dee-Designs
/
woocommerce
mirror of https://github.com/woocommerce/woocommerce.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
woocommerce/plugins/woocommerce-blocks/.wp-env.json

22 lines
499 B
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
{
Update @wordpress/env to 4.0.2 and test default config with core property set to null. (https://github.com/woocommerce/woocommerce-blocks/pull/4071) * update @wordpress/env to 4.0.2 * switch `core` to null for the default wp-env config * remove DT types for @wordpress/api-fetch and install actual api-fetch package as a dev dependency. The actual package now has types which are more up to date so it’s better to use it for the types than what’s in Definitely Typed.
2021-04-18 16:57:23 +00:00
"core": null,
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://downloads.wordpress.org/plugin/woocommerce.latest-stable.zip",
"https://github.com/WP-API/Basic-Auth/archive/master.zip",
Critical flows: Merchant → Checkout → Can adjust T&S and Privacy Policy options (https://github.com/woocommerce/woocommerce-blocks/pull/6211) * Add test to check if T&C and Privacy links are visible * Fix filling wrong type of form error With a virtual product we shouldn't need to fill the shipping details We need to fill the billing instead * Fix undefined 'termsCheckbox' bug * Fix terms checkbox name * Activate test case * Replace static URL with dynamic one * Convert external plugin into mock * Fix JS linting issue Co-authored-by: Saad Tarhi <saad.trh@gmail.com>
2022-04-25 08:48:54 +00:00
"./tests/mocks/woo-test-helper",
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
"."
],
"themes": [
E2E tests for Single Product Template (https://github.com/woocommerce/woocommerce-blocks/pull/5722) * Add empty block theme to mock E2E tests * Install empty theme in the test WP instance
2022-02-21 10:01:42 +00:00
"https://downloads.wordpress.org/theme/storefront.latest-stable.zip",
Add mock theme with Woo Templates for E2E tests (https://github.com/woocommerce/woocommerce-blocks/pull/5920) This PR adds a block-enabled theme with templates for WooCommerce which is intended to be used when testing the more complex scenarios such as template fallbacks. Additionally, since theme-dependent logic seems to be becoming more and more useful (see woocommerce/woocommerce-blocks#5913), this PR also adds a utility function used to explicitly declare theme dependencies of a test (`useTheme`). Said function will activate the theme before running a given suite and then reactivate the previous theme, as to make sure to not have any side-effects (such as the ones described in woocommerce/woocommerce-blocks#5913 above). Closes woocommerce/woocommerce-blocks#5660
2022-03-02 14:49:00 +00:00
"./tests/mocks/emptytheme",
"./tests/mocks/theme-with-woo-templates"
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
],
"mappings": {
".htaccess": "./bin/.htaccess"
Add JETPACK_AUTOLOAD_DEV to wp-env instances (https://github.com/woocommerce/woocommerce-blocks/pull/2960)
2020-08-05 10:28:11 +00:00
},
"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,
PHPUnit Tests running on wp-env (https://github.com/woocommerce/woocommerce-blocks/pull/4567) * Tidy up bootstap so it uses autoloaders and works with the known plugin paths * eslint ignore woocommerce bin * Use WC from bin in wp-env * Git ignore woocommerce in bin * Remove reliance on core framework across phpunit tests * Simplify bootstrap - since test framework is no longer required, there is no need to pull in woo from github * Remove unused configs * Update CI * Implement PHPunit Polyfill * Abstract the test case * Update lock * remove chown * experiment: try sudo * move phpversion to first run * Remove 7.0 tests :( * test plugin override for 5.5 test * Use dev version * Fix formatting Co-authored-by: Thomas Roberts <thomas.roberts@automattic.com>
2021-08-20 13:58:32 +00:00
"SCRIPT_DEBUG": false
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
}
}