Sometimes you run into this situation when a git pull will responds with `Merge conflict in config.php`. How to solve this issue in a proper way? Let's have a look how other people solve similar issues, namely my friend Mr. Rafael Dohms. Quite a while ago he blogged about a similar problem on how to solve conflicts in Composer's lock file. This is what I learned from his blog post:
This blog post has been sitting on my desk for quite a while but due to a lot of work in the last weeks I was not able to finish it earlier. Luckily, I found some time during my travels to finish the blog post and share my findings on the "require-dev gone wrong!" problem. While some people thought the former blog post was mostly click bait or proposed a "fix" which does not actually solve the general problem, I actually got a lot of good feedback on twitter. Even an issue for Composer was created to discuss the problem even though it was closed by now.
For a long time, I have been advocating to make use of require-dev to install development tools locally. We use this on a daily basis to install tools like Phing, PHPUnit or phpDocumentor locally for each of our (customer) projects. Given that our focus is on custom projects, this absolutely makes sense. I do not want our projects to use an old version of a given tool or update all our projects constantly to use the latest version of all the tools involved. In addition to that, a simple composer.phar install in the project root should be sufficient to install all dependencies required to build and run the project.
In my recent attempt to migrate away from our Jenkins infrastructure to the new GitLab CI Runner infrastructure I ran into a problem: Since we want to use Docker images for the GitLab CI builds I struggled a bit on how pass the authentication information for Satis and GitLab into the docker images. Since the base images - basic PHP setup - should be used for our projects I did not want to share the access credentials in the different base images. Gitlab's secret variables sounded like a good idea but unfortunately they need to be defined for each and every project. Currently we have more than 250 projects in our GitLab instance, configuring secret variables for all the projects would have been a big pain.
Am Donnerstag den 26.11.2015 trifft sich die Symfony Usergroup Frankfurt zum ersten Mal bei der Cocomore AG in Frankfurt. Ich freue mich dabei zu sein und werde meinen Vortrag "Composer im Unternehmensalltag" zu präsentieren.
Last week I gave my Composer for corporate use presentation at the code.talks 15 conference im Hamburg. In the section of my talk where I highlight how to work on multiple packages the same time (e.g. two applications sharing the same core functionality) I pointed to the audience to path repository feature of Composer. Unfortunately right after my session I began to realize that this is indeed the best feature we have out there when it comes to working on multiple packages the same time and to avoid the Satis or ToranProxy round trip. This is how it works: Add the following lines to your root composer.json file:
Am Montag den 09.03.2015 trifft sich zum ersten Mal die ZürichPHP Usergroup. Ich werde dort meinen Votrag "Composer for Corporate Use" halten und darstellen warum es Sinn macht Composer einzusetzen und wie man Composer konkret im Projektkontext einsetzen kann.
Recently we converted one of project to use Vagrant Rsync Folders instead of the default VirtualBox shared folders setup. After running the vagrant rsync-auto command for a while we realized that the symlinks in Composers ./vendor/bin/ where replaced with the content of the previously symlinked files. This made the commands unusable.
After a bit of investigation is was clear what was happening: Vagrant does not by default pass the -l flag to rsync which means symlinks are not preserved (even though the vendor folder was not copied to the guest vm). To fix this we had to adjust the rsync options by setting the rsync__args for the folder to:
Vom 03.10.2014 bis zum 05.10.2014 findet in Manchester die PHP North West Conference 2014 statt. Ich freue mich als Sprecher dabei sein zu können und meinem Vortrag "Composer for corporate use" präsentieren zu können.
Since we have to deal with a lot of private packages which cannot be shared on packagist I set-up a private Satis repo. Whenever a new version of a package gets created the Satis build process is started by our Jenkins build server. In the last couple of months this process takes quite a while because Satis rebuilds the index for every repo it knows about. Since we deal with quite a few repos containing a large amount of versions it slowed down the "build time". Obviously it does not make any sense to run Satis on a repo that has not changed. Since Satis was lacking this feature I started hacking on it and I am happy that the feature got merged into master this morning. If you have to deal with large repos or a large number of repos you might want to give it a try.This is how things work: