Build with DBAL 3

[greg0ire]

Please consider reviewing and merging #8872 first.

This is a work in progress, the plan as of now is to have 3 additional build jobs:

• 1 for phpstan
• 1 for Psalm
• 1 for Phpunit with SQLite

When those 3 are green, the next steps should be to run the PHPUnit jobs on more PHP versions (it only runs on 8.0 currently), and then to add more jobs depending on that job.

For static analysis, I used a variable, but for continuous integration, I don't think it's possible since it would make dependent jobs (about postgres, mysql, etc.) not run.

While I'm confident we will be able to fix the phpunit job, it might be more challenging to fix the Phpstan job without making the Phpstan job with DBAL 2 fail because it does not have the exact same baseline. We should not hesitate to remove it if that turns out to be the case IMO, but until then, it's good to have that information in the pipeline and ask the community for help in getting that DBAL 3 support 🙂

[greg0ire]

Maybe it would be better to use duplication for static analysis too 🤔
That way, we can customize the job title with something like Experimental, please disregard failures…

Also, it looks like having a failure in a matrix causes cancellation of other jobs of that matrix, so it would be one more reason not to use a variable.

[greg0ire]

Switching to fail-fast: false for now.

[greg0ire]

Cc @derrabus

[greg0ire]

I suggest we mark the regular static analysis jobs as required after merging this (I'm not sure why they were not in the first place)

[derrabus]

This pipeline looks good to me. The only concern I have is that to a external contributor, it might not be obvious which CI jobs are expected to fail at the moment.

[greg0ire]

@derrabus let me try to make it more obvious by using strings instead of booleans

[greg0ire]

I'm adding continue-on-error: true because it probably has an influence on the global status.

[greg0ire]

It does not seem sufficient, but I think I found an ugly solution: actions/runner#2347

[greg0ire]

Ok so now the situation is: we are pretending experimental jobs are green when they really aren't. That's great because the project still looks healthy (the global status is green), contributors aren't spooked, we can check the status of each job, and we can mark them as non-experimental as soon as they are green. WDYT?

[morozov]

To me, sounds exactly what the project needs. Until the build is green, each patch will be merged at the reviewer's discretion.

[morozov]

It does not seem sufficient, but I think I found an ugly solution: actions/runner#2347 (comment)

I'm curious if it could be implemented in the DBAL to re-enable PHP 8.1 builds.

[greg0ire]

I'm curious if it could be implemented in the DBAL to re-enable PHP 8.1 builds.

I think it could 👍