Testing against different versions of Sylius

[pamil]

No description provided.

[stefandoorn]

Example: https://github.com/stefandoorn/sitemap-plugin/blob/master/.travis.yml

[stefandoorn]

Also include a way to test <1.3 against PHP 7.1 while >= 1.3 it cannot use PHP 7.1..

Or: Sylius/Sylius#9838

[igormukhingmailcom]

This is an example how I've implemented that. (After that it was wiped out as far as finally we decided we don't need to test 1.2, so you will not find this at master):

Setono/SyliusCatalogPromotionPlugin@f7f85a5

The important thing here is to exclude incompatible sets (1.3+7.1) as far as it will make travis fail everytime.

[igormukhingmailcom]

Clean example:

# .travis.yml

env:
    matrix:
        - SYMFONY_VERSION="3.4.*" SYLIUS_VERSION="1.2.*"
        - SYMFONY_VERSION="4.1.*" SYLIUS_VERSION="1.2.*"
        - SYMFONY_VERSION="3.4.*" SYLIUS_VERSION="1.3.*"
        - SYMFONY_VERSION="4.1.*" SYLIUS_VERSION="1.3.*"
 matrix:
    exclude:
      # Sylius 1.3 won't work on PHP 7.1
      - php: 7.1
        env: SYMFONY_VERSION="3.4.*" SYLIUS_VERSION="1.3.*"
      - php: 7.1
        env: SYMFONY_VERSION="4.1.*" SYLIUS_VERSION="1.3.*"

# ...

 install:
    - composer require "symfony/symfony:${SYMFONY_VERSION}" --no-interaction --no-update
    - composer require "sylius/sylius:${SYLIUS_VERSION}" --no-interaction --no-update

[4c0n]

Although I am not a big fan of git submodules, so far it works for testing on multiple Sylius versions. I haven't gone through the extent of adding multiple Symfony versions and PHP versions, but that's not the hard part and has been done many times over.

https://github.com/4c0n/SyliusBarcodeSearchPlugin/blob/master/.travis.yml

Another option, at least for public repos, is to use flex to literally install the plugin in a new Sylius standard installation and then somehow run the tests. As this works for public repos only I haven't bothered, because I have to maintain plugins in private repos as well and don't like doing things differently there.

Hopes this helps getting this very old topic of the ground!

[4c0n]

The difference with the solution above is that this method allows you to keep multiple versions of the preconfigured test application on separate branches of a separate git repo. This will also allow you to run automated UI tests using Behat and Mink against different Sylius versions.

To be quite honest, I feel that a better solution would be to have a composer installer plugin for Sylius plugins, that allows for streamlining the plugin installation and updating. In a lot of plugins what we're doing is overriding templates for example, flex is okay at copying them for you, but what if you made changes of your own in the project? The only way you can know what to do right now is see if the docs tell you to do something and try to figure it out, every time you update for all plugins (but who is going to do that? right..) It's also not feasible to bump a major version every time a template is changed.

The installer plugin or "Sylius plugin installer composer plugin" to be clear :P could perhaps notify that changes have to be made to overridden templates and show a diff among other tasks yet to be determined.

Subsequently the "Sylius plugin installer composer plugin" can then be used to install the plugin in a clean Sylius instance on the CI, providing clean room testing of the plugins installation/update process at the same time.

[4c0n]

@pamil You were asking about custom config in the submodule?