This is the development repo for mu-plugins on VIP Go.
Please, visit our Enterprise Search documentation to learn more.
We recommend using the VIP local development environment for local development: https://docs.wpvip.com/technical-references/vip-local-development-environment/
We also have to ensure that we have our dependencies installed - so first, run the following:
git submodule update --init --recursive
composer install
npm install
To use mu-plugins code in a "hot-reload" fashion you need to specify the local folder to which this repository is cloned. For example:
vip dev-env create --mu-plugins $(pwd)
You will be prompted to configure other options of the environment. When the environment is created you can start it with:
vip dev-env start
npm run phplint
We use eslines to incrementally scan changed code. It will automatically run on pre-push (see .huskyrc.json
).
This is also run on Circle CI for all PRs.
If you want to scan the entire codebase:
npm run phpcs
If you don't have the Lando-based environment running (e.g. in a CI context), we have a script that runs unit tests in a self-contained Docker environment. To run these tests, execute the following from the project root:
./bin/test.sh
You can also filter by test name.
./bin/test.sh --filter test__rate_limit_ep_query_integration__clears_start_correctly
See ./bin/test.sh
for more options.
PHP Linting and PHPUnit tests are run by Circle CI as part of PRs and merges. See .circleci/config.yml
for more.
We run core tests as part of the CI pipeline. There are many failures when running with mu-plugins so we had to ignore several tests. To add another test there check bin/utils.sh
.
To investigate failing test locally you can do following (buckle up as this is not so easy:()):
-
While in your mu-plugins folder do
MU_PLUGINS_DIR=$(pwd)
-
Switch to where you want to checkout core code e.g.
cd ~/svn/wp
-
Checkout the core code (pick the latest version):
svn co --quiet --ignore-externals https://develop.svn.wordpress.org/tags/5.5.3 .
-
Create test config:
cp wp-tests-config-sample.php wp-tests-config.php && sed -i 's/youremptytestdbnamehere/wordpress_test/; s/yourusernamehere/root/; s/yourpasswordhere//; s/localhost/127.0.0.1/' wp-tests-config.php
-
Build core
npm ci && npm run build
-
Export env variable
export WP_TESTS_DIR="$(pwd)/tests/phpunit"
-
Start local DB:
docker run -d -p 3306:3306 circleci/mariadb:10.2
-
Create empty DB
mysqladmin create wordpress_test --user="root" --password="" --host="127.0.0.1" --protocol=tcp
-
Copy over MU-plugins
cp -r $MU_PLUGINS_DIR build/wp-content/mu-plugins
-
Run the test you want (in this case
test_allowed_anon_comments
)$MU_PLUGINS_DIR/vendor/bin/phpunit --filter test_allowed_anon_comments
A new release of the plugin consists of all those pull requests that have been merged since the last release and have been deployed to Staging (i.e. have the [Status] Deployed to staging label. Releases are named after the day they are released plus a minor version:
YYYYMMDD.x
e.g: 20210917.0
Releases are created using GitHub's releases and are effectively a tag in the GitHub repository. Previous releases can be found here.
To create a new production release:
- Create a new PR: https://github.com/Automattic/vip-go-mu-plugins/compare/production...staging
- Name it
Production release: vYYYYMMDD.0
. - After carefully reviewing and making sure all test have passed, merge it.
- The changelog will be generated automatically, and a bot will ping you to proof-read the draft
- Any follow-up releases on the same day should increment the last number. E.g.
Production release: vYYYYMMDD.0
To create a new staging release, follow the same steps but name the release Staging release: vYYYYMMDD.1
(assuming production release has been tagged already.)
https://github.com/Automattic/vip-go-mu-plugins/compare/staging...develop
For Automattic Use: Instructions are in the FG :)
This is a repo primarily meant for local non-development use.
Every commit merged into develop
is automatically pushed to the public copy at Automattic/vip-go-mu-plugins-built. This is handled via CI by the deploy
action, which pushes a copy of this repo and expanded submodules.
We use a script to generate changelog entries. This can be debuged by running:
php ci/changelog-summary.php --debug --dry-run --force --merge-pr 4673 --github-project-username Automattic --github-project-reponame vip-go-mu-plugins