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.
While working with Zend Expressive, a PSR-7 middleware microframework, I wanted to apply some unit testing with a nice coverage to my middlewares. Middlewares are called by the __invoke method if you provide them as an object and not as a closure. The signature of the __invoke method looks like this:
Yesterday, we released the stable version 2.0 of our Force Login Module for Magento 2. To upgrade, you can get the latest release here, or update the dependency in your composer.json.
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.
Using the JMS serializer in recent project, I ran into the problem that the serializer does not support inheritance in a handler configuration. A handler is used to to change the serialization, or deserialization process for a single type/format combination.
In our "old" Jenkins set-up things were simple: The Jenkins master and Satis were running on the same host thus Jenkins could easily invoke Satis via a command-line call. Unfortunately GitLab does not allow that. The only option which is currently available in GitLab is to trigger Satis via a webhook. Neither Satis itself or Satisfy which we actually use provide support for webhooks. Thus we extended Satisfy with a simple controller which invokes the Satis cli command. Definitely not the best solution but it works for us.
A few months back I was looking for a HTTP reverse proxy and load balancer to put in front of our Docker setup. By accident I came across traefik. I deployed it on one of our internal servers and it worked out-of-the box. Recently we configured a Docker setup for one of our clients and I picked traefik again. Since this setup will host some public instances the customer demanded SSL encryption. Luckily traefik comes with support for Let's Encrypt built in. I added the needed configuration to the traefik configuration file:
Finally PSR-11 - the Container standard - got approved by the PHP FIG. To celebrate this fact I just merged a PR to make Disco PSR-11 compatible. The latest 0.8.0 release is compatible with the 0.7.0 relase. The only difference being that 0.7.0 relies on the container-interop standard and the 0.8.0 release relies on the PSR-11 standard.
Recently I was in the need to create multiple directories at once in my Dockerfile. Using bash as a shell the shell expansion feature comes in handy:
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.