search

symfony-cmf / seo-bundle

A SEO Solution for duplicate contents, page titles, etc.
https://cmf.symfony.com
47 stars 27 forks source link

[POC] use make file #336

Closed ElectricMaxxx closed 6 years ago

ElectricMaxxx commented 7 years ago

This would be my first try to use make files and instantiate database there instead of using the DatabaseListener. What do you think?

fix #334

ElectricMaxxx commented 7 years ago

@dbu you got an idea, why the hhvm build fails now?

dbu commented 7 years ago

hhvm

had no idea either, so i re-started the last successful test of the master branch. it fails with the same error, so it looks like a setup change at travis-ci rather than something of this branch. we said we keep hhvm support as long as the hassle is not too big - sounds to me like the moment to drop it, honestly.

ElectricMaxxx commented 7 years ago

btw: the broken installation build depends on the release of: https://github.com/sonata-project/SonataSeoBundle/commit/181215ef16f29eded95cc79d5a2cb7f4c7ca1316

ElectricMaxxx commented 7 years ago

I am now behind master-dev-kit with this, as dev-kit introduces the makefile and tranvis checks there. I also added Symfony 3.4 and 4.0 there lets see what happens :-)

ElectricMaxxx commented 7 years ago

aaaand ... we see the stricter style checks now.

ElectricMaxxx commented 7 years ago

argh, now we collide with sonata's php 7.1 requirement. We have to follow now too.

ElectricMaxxx commented 7 years ago

Except the fail on prefer lowest and symfony 4.0 it looks good with php 7.1. Both should be caused by sonata-seo. I would like to get 2.2.1, which isn't released jet. But dumping php 7.0 and 5.6 sounds like a BC for me.

dbu commented 7 years ago

But dumping php 7.0 and 5.6 sounds like a BC for me.

its not. composer will prevent from installing on outdated systems. lets jump to php 7.1. people on legacy system can keep using the 2.0 version of seo and sonata.

ElectricMaxxx commented 7 years ago

i also added symfony: ^4.0, and also did on testing component. But it fails caused by other dependencies, should i keep it or is^3.4` enough?

ElectricMaxxx commented 7 years ago

btw: @dbu you know a fix for our red prefer-lowest build: https://travis-ci.org/symfony-cmf/seo-bundle/jobs/289844120 some other phpunit version?

dbu commented 7 years ago

lets get things working as is and add symfony 4 later in a separate pull request to not complicate things.

about the build failure: thats really odd. the phpunit bridge is installing phpunit and we get the exact same version. however, something also installs sebastian/exporter as a composer dependency. can you check with composer why which dependency causes that? i would have thought that phpunit would use its own classes also for dependencies, rather than those of the project, but that seems not to work that way.

ElectricMaxxx commented 6 years ago

Awesome, moving assertEquals to assertSame breaks some tests. So i will remove that php_unit strict thing.

dbu commented 6 years ago

this is better, but not fully good. can you try ^3.3.10 to get the latest 3.3 version?

dbu commented 6 years ago

still same problem. can you try bumping the noback things to the latest version?

ElectricMaxxx commented 6 years ago

I think our tests are not compatible with phpunit 6.*, or?

dbu commented 6 years ago

i guess not. if all php versions we want to test with are compatible with phpunit 6, we should just upgrade to that. but if not, lets find something that is new enough to work but not too new...

ElectricMaxxx commented 6 years ago

so i will try to go on phpunit 6.0, cause there is no version of the mathiasnoback stuff in between. But this couls possibly mean we have to lift testing component, and we have to lift all packages in their php versions :-)

ElectricMaxxx commented 6 years ago

i will merge this one into the master-dev-kit to have one open PR here only.