2

I have a Neos project, consisting of a Site providing the main composer container. composer.json requires a huge number of packages (whole neos/flow environment), including some packages we develop.

Our deployment setup consists of Jenkins, building the css/javascript for both the site and plugin packages (only within their specific gits) and finally triggering TYPO3 Surf, which actually calls composer install and then rsync's to the server.

Right now, each time we want some changes in our dev branch to be deployed to the testing environment, we have to manually cd to the main composer directory, do a 

composer update vendor/package && git add composer.lock && git commit -m "update composer.lock"`.

Is there anyway to always use the newest version of our plugin package with composer? Perhaps excluding the requirement from composer.lock, or just changing it without installing the actual packages.

StephenKing
  • 36,187
  • 11
  • 83
  • 112
O.Heins
  • 33
  • 4

1 Answers1

1

For a continuous deployment to a testing server you could just make jenkins do a composer update and with your packages set to dev/master in the composer.json.

StephenKing
  • 36,187
  • 11
  • 83
  • 112
dlienert
  • 228
  • 1
  • 4
  • 1
    You could also just do `composer update your/package` for the testing server. – ChristianM Jun 19 '15 at 07:17
  • The problem with the `composer update my/package` approach is where to put in the build process. Three Jenkins processes are running: the first one fetches the site (and thus the main composer definitions, including the plugin, but also the whole Neos stuff) and then runs grunt. The second one does the same for the plugin. The third one triggers Surf to do the actual deployment. If I run `composer update my/package` within the first job, composer will fetch unnecessarily all dependencies. I want to avoid that overhead and possibly just update the composer.lock here. – O.Heins Jun 19 '15 at 08:46