woocommerce/plugins/woocommerce-blocks/.travis.yml

156 lines
4.3 KiB
YAML
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
language: generic
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
services:
- docker
cache:
directories:
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
- $HOME/.jest-cache
- $HOME/.nvm/.cache
- $HOME/.npm
- $HOME/.composer/cache
branches:
only:
2020-06-16 09:38:19 +00:00
- main
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
# Make sure NodeGit gets the correct C libs.
addons:
apt:
sources:
- ubuntu-toolchain-r-test
packages:
- libstdc++-4.9-dev
before_install:
- timedatectl
- nvm install --latest-npm
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
- |
if [[ ! -z "$E2E_TESTS" ]]; then
# Upgrade docker-compose.
sudo rm /usr/local/bin/docker-compose
curl -sL https://github.com/docker/compose/releases/download/1.24.0/docker-compose-`uname -s`-`uname -m` > docker-compose
chmod +x docker-compose
sudo mv docker-compose /usr/local/bin
fi
before_script:
- export PATH="$HOME/.composer/vendor/bin:$PATH"
- |
if [ -f ~/.phpenv/versions/$(phpenv version-name)/etc/conf.d/xdebug.ini ]; then
phpenv config-rm xdebug.ini
else
echo "xdebug.ini does not exist"
fi
- |
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
if [[ ! -z "$PHP_UNIT" ]]; then
composer install
fi
- |
if [[ ! -z "$E2E_TESTS" ]]; then
composer install --no-dev
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
npm ci
if [[ ! -z "$GUTENBERG_LATEST" ]]; then
JSON='{"config": { "SCRIPT_DEBUG": false } }'
else
JSON='{"core": "WordPress/WordPress#'"$WP_VERSION"'", "config": { "SCRIPT_DEBUG": false } }'
fi
echo $JSON > .wp-env.override.json
npm run build:e2e-test
chmod -R 767 ./
npm run wp-env start
fi
- |
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
if [[ "$WP_TRAVISCI" == "phpcs" ]]; then
composer install
fi
Fix wp-cli container permissions issues for e2e docker test environment (https://github.com/woocommerce/woocommerce-blocks/pull/1716) * add docker files * get tests to work * remove irrelevant files * change userAgent to chrome * add woocommerce as a dep * add jest to eslint * remove eslintignore for tests * undo travis chages till another PR * remove local utils and call them directly from woocommerce * update deps * add setup files to run tests * export default wp link * wait for select before selecting * remove travis db * ignore e2e tests in unit testing * add tests * add docker commands * always run composer * Make it possible to import directly from '@woocommerce/e2e-tests/utils' * remove installing woocommerce via composer. * add more docker npm scripts * add custom docker config for wp-cli * add changes to docker-composer.yml Includes reading environment variables from `.env` * revert customizations to .travis.yml * move main docker file for the wordpress container to bin * fix travis config * rename wp install for travis builds back to original name * use a version of docker-compose that travis supports * add minor change to try and force travis test run * fix incorrect command * copy composer lock from master * only run phpcs on /src directory * give time for host to spin up for e2e tests * increase sleep for waiting on container * make sure plugin is built before running tests * sigh fix improper command usage Co-authored-by: Seghir Nadir <nadir.seghir@gmail.com> Co-authored-by: Albert Juhé Lluveras <aljullu@gmail.com>
2020-02-11 16:13:20 +00:00
jobs:
fast_finish: true
include:
- stage: build tests
name: PHP 7.1/unit-tests/Latest WP
php: 7.1
env:
- WP_VERSION=latest
- WOOCOMMERCE_BLOCKS_PHASE=3
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
- PHP_UNIT=1
script:
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
- npm run phpunit
- name: PHP 5.6/unit-tests/Latest WP
php: 5.6
env:
- WP_VERSION=latest
- WOOCOMMERCE_BLOCKS_PHASE=3
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
- PHP_UNIT=1
script:
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
- npm run phpunit
- name: PHP Linting Check
php: 7.3
env:
- WP_TRAVISCI=phpcs
- WOOCOMMERCE_BLOCKS_PHASE=3
script:
- npm run lint:php
- name: Javascript Tests
script:
- npm install
- npm run test
env:
- WOOCOMMERCE_BLOCKS_PHASE=3
- name: Javascript/CSS Lint check
script:
- npm install
- npm run lint:ci
env:
- WOOCOMMERCE_BLOCKS_PHASE=3
- name: E2E Tests (WP 5.2)
Fix wp-cli container permissions issues for e2e docker test environment (https://github.com/woocommerce/woocommerce-blocks/pull/1716) * add docker files * get tests to work * remove irrelevant files * change userAgent to chrome * add woocommerce as a dep * add jest to eslint * remove eslintignore for tests * undo travis chages till another PR * remove local utils and call them directly from woocommerce * update deps * add setup files to run tests * export default wp link * wait for select before selecting * remove travis db * ignore e2e tests in unit testing * add tests * add docker commands * always run composer * Make it possible to import directly from '@woocommerce/e2e-tests/utils' * remove installing woocommerce via composer. * add more docker npm scripts * add custom docker config for wp-cli * add changes to docker-composer.yml Includes reading environment variables from `.env` * revert customizations to .travis.yml * move main docker file for the wordpress container to bin * fix travis config * rename wp install for travis builds back to original name * use a version of docker-compose that travis supports * add minor change to try and force travis test run * fix incorrect command * copy composer lock from master * only run phpcs on /src directory * give time for host to spin up for e2e tests * increase sleep for waiting on container * make sure plugin is built before running tests * sigh fix improper command usage Co-authored-by: Seghir Nadir <nadir.seghir@gmail.com> Co-authored-by: Albert Juhé Lluveras <aljullu@gmail.com>
2020-02-11 16:13:20 +00:00
script:
- npm run test:e2e
Fix wp-cli container permissions issues for e2e docker test environment (https://github.com/woocommerce/woocommerce-blocks/pull/1716) * add docker files * get tests to work * remove irrelevant files * change userAgent to chrome * add woocommerce as a dep * add jest to eslint * remove eslintignore for tests * undo travis chages till another PR * remove local utils and call them directly from woocommerce * update deps * add setup files to run tests * export default wp link * wait for select before selecting * remove travis db * ignore e2e tests in unit testing * add tests * add docker commands * always run composer * Make it possible to import directly from '@woocommerce/e2e-tests/utils' * remove installing woocommerce via composer. * add more docker npm scripts * add custom docker config for wp-cli * add changes to docker-composer.yml Includes reading environment variables from `.env` * revert customizations to .travis.yml * move main docker file for the wordpress container to bin * fix travis config * rename wp install for travis builds back to original name * use a version of docker-compose that travis supports * add minor change to try and force travis test run * fix incorrect command * copy composer lock from master * only run phpcs on /src directory * give time for host to spin up for e2e tests * increase sleep for waiting on container * make sure plugin is built before running tests * sigh fix improper command usage Co-authored-by: Seghir Nadir <nadir.seghir@gmail.com> Co-authored-by: Albert Juhé Lluveras <aljullu@gmail.com>
2020-02-11 16:13:20 +00:00
env:
- WP_VERSION=5.2
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
- E2E_TESTS=1
- WOOCOMMERCE_BLOCKS_PHASE=3
- name: E2E Tests (WP 5.3)
script:
- npm run test:e2e
env:
- WP_VERSION=5.3
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
- E2E_TESTS=1
- WOOCOMMERCE_BLOCKS_PHASE=3
- name: E2E Tests (WP 5.4)
script:
- npm run test:e2e
env:
- WP_VERSION=5.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
- E2E_TESTS=1
- WOOCOMMERCE_BLOCKS_PHASE=3
- name: E2E Tests (WP 5.4 with Gutenberg plugin)
script:
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
- npm run wp-env run tests-cli "wp plugin install gutenberg --activate"
- npm install @wordpress/e2e-test-utils@latest
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
- chmod -R 767 ./
- npm run test:e2e
env:
- WP_VERSION=5.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
- E2E_TESTS=1
- GUTENBERG_LATEST=true
- WOOCOMMERCE_BLOCKS_PHASE=3
- stage: deploy
2020-06-16 09:38:19 +00:00
if: (NOT type IN (pull_request)) AND (branch = main)
name: Deploy Storybook
env:
- WOOCOMMERCE_BLOCKS_PHASE=3
install:
- npm ci
2020-03-22 16:31:57 +00:00
script:
- npm run storybook:build
deploy:
provider: pages
2020-03-22 16:31:57 +00:00
skip_cleanup: true
github_token: $GITHUB_TOKEN
keep_history: true
local_dir: storybook/dist
on:
2020-06-16 09:38:19 +00:00
branch: main