application.type: symfony2 - would not boot

[adamjakab]

Hi, I have an issue with a symfony project. It is a container project much like symfony/standard-edition with some custom stuff.

In fact, the below config section is auto-generated

application:
    type: symfony2
    boot_commands:
        inference:
            - 'composer install --prefer-dist'

and the result is this:

The above error occurs always around 2:22 (seems like a joke) and I guess it is about composer operation timeout.

The only way I can pass this booting phase is by setting type: none in my config.

I also saw that I can add custom commands under boot_commands with specific "idle_timeout" but it seems that the inferred command which I cannot overwrite is executed first - and fails

I have also tried to put { command: 'composer install --prefer-source --no-interaction', idle_timeout: 1800 } in before_commands but it gets removed.

Any ideas woh to make it work - TBH i don't really know what this booting stuff does for me (dependency tests?) but I guess if it is there it makes sense to be there.

Any ideas?

[LewisW]

We have a similar issue, we can't override the boot options and it tries to clear the cache of our Symfony app with warm up enabled (which tries to connect to the database, thanks to FOSUserBundle). It really shouldn't clear the cache with warm-up, it's quite often that a warm-up command will pull things from the database.

[adamjakab]

My trouble was/is caused because I did not want to commit the composer.lock file in the repository. In fact if I do commit the lock file the boot command completes in 5-10 seconds but without it (obviously) it needs much more time to figure out the dependencies starting from the composer.json alone. In fact both the scrutinizer documentation and the composer documentation suggests to do commit the lock file. So I did and now my problems are gone. What I find strange is that on github I seem to find nearly all projects without the composer.lock file - even the ones with .travis.yml and they all build fine. @LewisW - I think you are a step ahead of me in this because if your problem is warm cache your app is already up - I wouldn't know what to do in that case.

[LewisW]

@adamjakab The general consensus is composer.lock is committed for projects, but not packages. I think the reason is if your package is being distributed and used by others as a dependency then you can't rely on composer.lock to give your package a fixed set of dependencies. So package maintainers avoid committing the lock file to force the build platform to run the tests with the latest versions of its dependencies. Otherwise, one of these packages may introduce an update that breaks your package, and that's the version that most users of your package would also get when installing your package. That way, you can change your composer.json to limit the requirements for the versions if there is a problem.