24 posts tagged with "Composer"

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 folder 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.

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:

Thanks to a Pull Request by Jérôme Vieilledent I was able to create a new version (0.2) of the authstore plugin for Composer. The latest version of the plugin allows you to store the auth credentials inside your project folder. Simply add a file named auth.json to your project folder next to your composer.json file which looks like this:

As I blogged recently we solved the HTTP Basic Auth problem with Composer / Satis by using expect. I still like the general idea but expect can be a bit tricky to configure. For those of you who are not happy with that solution this one might be a good alternative: As I helped out Manuel Lemos to create an Composer Installer for phpclasses.org packages he pointed out that the new Composer Plugin API might make it easier to extend Composer and offer authentication support. And yes he was right ;) As I had some spare time last weekend I extracted the code handling the authentication logic from his installer and created a separate plugin which can be found on github and packagist.org.