ci(phpunit): cache the installed database, key the cache on the Shopware version
plugin-checks / version-changelog (pull_request) Successful in 16s
plugin-checks / phpunit (pull_request) Failing after 27s
plugin-checks / package (pull_request) Successful in 59s

- resolve the latest 6.6.x from Packagist; cache key shopware-<version>-installed-v1
- cache the project plus a SQL dump of the installed shopware_test database; on a hit restore
  the dump instead of running system:install (~4.6 min)
- rename the step 'Install Shopware (once)' to 'Install Shopware'

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This commit is contained in:
haylanandClaude Bot committed 2026-10-04 01:01:21 +02:00
1 parent eb2a3172e5
commit 18844718d2
2 files changed
+66 -26

No files matched your search

+5 -3
View File
@@ -53,9 +53,11 @@ activates this plugin inside a real Shopware kernel for the test run (`KERNEL_CL
`Shopware\Core\Kernel` in `phpunit.xml`). This means tests require a working Shopware installation/DB
to bootstrap against — they are not runnable as an isolated PHP package.
In CI (`phpunit` job) a Shopware 6.6 project is prepared once (`composer create-project` + phpunit,
cached monthly), the plugin is copied into `custom/plugins`, and `system:install` runs once into
`shopware_test` (MariaDB 10.11 service), so the bootstrapper only activates the plugin.
In CI (`phpunit` job) the latest Shopware 6.6 version is resolved from Packagist and the prepared project
(`composer create-project` + phpunit, then `system:install` into `shopware_test` on a MariaDB 10.11 service)
plus a SQL dump of the installed database are cached under a key that contains that version, so a new
Shopware release invalidates the cache. On a hit the dump is restored instead of reinstalling; the plugin
is then copied into `custom/plugins` and the bootstrapper only activates it.
```bash
vendor/bin/phpunit # full suite