Let's not deny that GitHub actions are hitting hard in the tech community, and many projects are transitioning from other continuous integration systems like Circle CI or Travis CI.

Personally I have been using Travis a lot during the past years, for all my OSS projects, and I have gotten very used to it.

However, people seem to be "abandoning" travis in favor of GitHub Actions, for different reasons. "It's faster", "I can run smaller tasks in parallel", etc.

In my case, I have moved a few very specific tasks there, where travis was becoming a bottleneck, but I still have mixed feelings about the very-verbose yaml-based config needed to configure a few GitHub Actions, compared to the more concise travis one.

Asynchronous and non-blocking runtimes are pretty usual in many programming languages, as well as long-lived web apps that stay in memory and are capable of dispatching multiple HTTP requests without having to be fully bootstrapped every time. This has not been traditionally the case with PHP apps.

However, many projects are starting to get some adoption, that bring this long-lived approach to the PHP world.

The problem with this is that PHP developers are not used to this, and they tend to continue acting as they have always done. Also, libraries might have made some assumptions, making them not work as expected when used under this context.

Some of you probably know that I have a pet project in which I like to work from time to time. This project is a self-hosted URL shortener called Shlink.

Shlink is built using expressive as the base framework for the HTTP-dispatching task. A while ago, an expressive module was released to officially support serving expressive apps with swoole, and I decided to include it on Shlink.

How does swoole work?

Swoole is an asynchronous non-blocking I/O framework which works in a similar way as node.js, but for PHP apps.

It has been conceived in a way that the app stays in memory between requests, removing the bootstrapping step and making apps to be served much faster.

For a long time, I have been trying to include tests in every project in which I've worked on.

There are several types of automated tests (or what should actually be called automated checks). From unit tests, integration and functional tests, to end-to-end tests.

Each one of them differs from the rest by the scope they try to cover. From small units of code which are tested completely detached from external dependencies, to a whole app which is tested as a black box like if an end consumer was using it.

I'm not going to deeply discuss the semantics behind this, or where an integration test ends and an end-to-end test starts, because it's quite frequently a blurry line.

I've been wanting to write this article for a while, but it is a subject complex to approach.

Lately I've had some "conflicts" with users in some of the open source software (OSS) projects I maintain, and I have also seen some of the people I follow on Twitter dealing with the same.

Because of that I wanted to share my point of view on what should be the attitude and considerations when using OSS.

Company vs personal

The first thing you have to take into account when using OSS, is that there are two kinds of projects which usually have different goals.

Company projects

It is very common that companies which activity is related with software or make a deep use of technology, publish their own OSS projects.