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.
Using Composer in your Vagrant / Puppet setup is as simple as this:
Vom 24.02.2014 bis zum 28.02.2014 findet in Montreal die ConFoo 2014 Konferenz statt. Ich bin dieses Mal wieder dabei und kann zwei neue Vorträge präsentieren: Im Vortrag "The seven deadly sins of Dependency Injection" möchte ich darstellen welche Fehler man bei der Verwendung des Dependency Injection Patterns nicht machen sollte. Der Vortrag "The Setup: Composer, Phing, Vagrant, Jenkins" beleuchtet unsere Arbeitsweise mit den genannten Tools soll aufzeigen wie man mit den Tools arbeiten kann (aber nicht muss).
A couple of months ago when we set-up our own internal Satis repository to host our custom Composer packages. We ran into an "unpleasant" issue with Composer that had this PR as an result. To sum things up: We are using HTTP Basic Auth to password-project our Satis repository. There was no way we could switch to an SSL client certificate to allow Composer to authenticate itself automatically without asking for a password. Asking for the password on a developer`s machine is no big thing, but it since we need an automated Composer run in our Jenkins environment, there was no way to set things up. Unfortunately the PR is not yet merged in master so we were in need to find a different solution. Luckily my friend Joshua Thijssen pointed me to a tool named expect which could solve this issue easily. Expect is a tool that "talks to other interactive programs according to a script." which sounds pretty awesome and yes it is ;)
Seit wenigen Tagen sind wir nun mit unserer überarbeiteten bitExpert Webseite und dem überarbeitenden Blog online. Statt Contenido und Wordpress nutzen wir nun Silverstripe als Basis für beide Auftritte. Dies hat den Vorteil dass wir die Templates nur einmal bauen mussten und in beiden Auftritten verwenden konnten. Dank Composer war das Dependency Management der verwendeten Pakete ein Kinderspiel. Wiederverwendung at it`s best ;)