[Feature Request] improve usability for CI cases when SecurityAdvisories is pulled in by a dependency

[gggeek]

Today the Travis tests for one of my bundles started failing with no apparent reason in its code (log: https://travis-ci.org/kaliop-uk/ezmigrationbundle/jobs/395645840 )

The travis log tells me that composer failed to install the dependencies - but in a quite non obvious way, as the offending package is listed as being 'roave/security-advisories dev-master', instead of the one that SecurityAdvisories conflicts with.

It might well be that this is rather a composer problem with not giving more detailed information about the conflict - but in the current situation it is hard for me to find out which package prevents composer to achieve an installation, as the list of dependencies is huge.

It is also not as easy to simply 'not include SecurityAdvisories' in the composer.json that I use for Travis tests, as it is in fact pulled in by a dependency (my bundle is a plugin for a cms, and it pulls in the cms as dependency when running its test suite. The cms seems to be the one now including SecurityAdvisories).

And all things considered, I'd rather still run my tests against a complete matrix of versions of the supported core system, even though some of those might now be known to have security issues.

It would be nice to have at least some tips for working around this situation in the Readme file...

[Ocramius]

If you have this package in your dependencies, chances are that you are testing an application, not a library.

If that is the case, then you should use composer install, and have a separate task running composer update and committing upgrades regularly.

[gggeek]

My own package is a library; it works as add-on to an application. It does not have a composer.lock file committed to the sources. The application does have this package as a dependency, as well as a composer.lock in its sources. It might run composer update regularly - or not: in any case this is outside my control.

In order to run the test suite for the library, I need to have the whole application available. So, in my travis setup scripts, I add the application as a requirement, and run composer update. Even though this is a bit upside-down compared to the default workflow that any developer would use when installing the application, it does work well. I could probably rewrite the travis setup scripts and parts of test suite so that the application would get installed first and my library then added to it, but this would entail a considerable effort.

[Ocramius]

If it is a library, then you should probably not rely on this package, because you are also forcing it down to consumers.

[gggeek]

I am not relying on this package. The application is.

[Ocramius]

Looks like the problem is in ezsystems/ezplatform. Is that supposed to be a library or an application?

[gggeek]

that's the application :-)

[Ocramius]

Right, so your bundle requires an application, which should probably be a locked dependency (with all its deps locked too). Is there nothing lower level (library-alike) that you can rely upon instead?

[gggeek]

My bundle needs the full application for its test suite. It also make sense that it declares to depend on the full application and not to anything lower-level, as in the end it is just a plugin for that application. My bundle works with multiple version of the application, so it makes no sense that I lock down the application to as specific version as dependency of the bundle.

[gggeek]

PS: I ended up with this solution: https://github.com/kaliop-uk/SecurityAdvisoriesNoConflicts plus https://github.com/kaliop-uk/ezmigrationbundle/commit/5ed2013923fe9637646ac41f00c6f1bd99a2ebac

[Ocramius]

Yeah, this is an edge case that this package cannot solve. The edge case, to be clear, is that you are depending on an application rather than a library.

In theory, anything range-based should indeed fail by design, so IMO it makes no sense to test ranges that contain vulnerable code, because those are already red (that code is not usable anymore).

That said, clever solution you got there, nice! Still wouldn't endorse it.

I see you do composer require --dev --no-update ${EZ_PACKAGES}: use a composer range of supported versions instead, and use --prefer-lowest --prefer-stable to test ancient code. Note that people relying on your package cannot install older EZPlatform versions anyway, since there's security-advisories as transient dependency.

[Ocramius]

See https://github.com/doctrine/doctrine2/blob/v2.6.1/.travis.yml#L54L63 for an example of this

[Ocramius]

Ah, there is another possibile resolution (which will only work for newer releases though): move roave/security-advisories to "require-dev" in EZPlatform