When we made the move to GitLab 1,5 years ago, it was clear to me that we would need some automation to simplify the creation of groups and projects and to sync the LDAP group memberships to the matching GitLab groups. I did a quick search on Packagist for GitLab client libraries and found the m4tthumphrey/php-gitlab-api package.

I wasn't really happy with the current approaches of dealing with different Dockerfiles and docker-compose.yaml files for development and production containers. I don't really see the point of managing multiple configuration files, building a few intermediate containers when the only difference between a development image and a production image is that the code is copied into the image during build. Adding files on every build is also not an ideal solution as you could potentially ship an old version of the application when you miss running a docker build after you made your final changes.

In my recent talk on introducing Disco - the DI container with the damn coolest name(tm) - I talk about why I believe that using XML or any other non-code configuration (YAML, JSON, ...) is not a good idea. This stirred some twitter discussion recently which led to this blog post.

In a recent attempt to automate a few things even more, I was looking for a way to post messages to our Mattermost instance via the Incoming Webhook feature of Mattermost. I did a quick search on Packagist for Mattermost client libraries and as it turns out there a quite a few. I picked the thibaud-dauce/mattermost-php package simply because it was the first match ;)

When providing and consuming webservices both sides do their best to fulfill the WSDL contract. But what if one side can not fulfill the contract? To be concrete, the client sends us SOAP requests but omits the application's namespace. So instead of:

Last week we released Disco version 0.9.0 with a few new features and unfortunately some BC breaks. The BC breaks are all covered in the upgrade guide, but I would like to discuss them in greater detail to give you a better understanding why those changes happened:

Since the first release of our ng2-combobox components for Angular the repository is still lacking a decent documentation on how to use the component if you are not that familiar with Angular. This blog post should give you some insights on how to set up the combobox component in an Angular application. If you haven't yet set up an Angular application yourself it is as simple as typing the following command:

Last year GitLab introduced the Review Apps feature. Review Apps are app environments that are created dynamically every time you push a new branch up to GitLab. As a bonus point the app environments are automatically deleted when the branch is deleted. Since we moved to using docker for quite a few of our projects I was keen on figuring out how to combine Docker and the GitLab Review Apps functionality as the documentation only mentions NGINX as a way to run Review Apps. As it turns out, it is rather simple to deploy docker containers as a Review App.

In a recent attempt to upgrade Disco to the latest version of ProxyManager I ran into this FATAL ERROR: "Declaration of Mock_ClassGenerator_f7ebad25::setExtendedClass($extendedClass): ProxyManager\Generator\ClassGenerator must be compatible with ProxyManager\Generator\ClassGenerator::setExtendedClass($extendedClass): Zend\Code\Generator\ClassGenerator" when I tried to execute the unit tests. It took me a while to understand the source of the problem, thus I think sharing the problem might help my future me and probably you as well. Let's assume you have two classes The_Parent and The_Child:

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.