Build with DBAL 3 #8874
Build with DBAL 3 #8874
Conversation
greg0ire
force-pushed
the
build-with-dbal-3
branch
3 times, most recently
from
14fa43f
to
6d59e23
Compare
|
Maybe it would be better to use duplication for static analysis too 🤔 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
force-pushed
the
build-with-dbal-3
branch
from
6d59e23
to
5e82e77
Compare
|
Switching to |
greg0ire
force-pushed
the
build-with-dbal-3
branch
3 times, most recently
from
d6d39ac
to
08aa97d
Compare
|
Cc @derrabus |
|
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) |
|
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. |
|
@derrabus let me try to make it more obvious by using strings instead of booleans |
greg0ire
force-pushed
the
build-with-dbal-3
branch
from
08aa97d
to
80dd089
Compare
greg0ire
force-pushed
the
build-with-dbal-3
branch
from
80dd089
to
ae20df2
Compare
|
I'm adding |
|
It does not seem sufficient, but I think I found an ugly solution: actions/runner#2347 |
greg0ire
force-pushed
the
build-with-dbal-3
branch
from
e767160
to
e142ed3
Compare
Making these jobs green will not result in a comprehensive result of the features, but it is a good start, and having them should give a good overview of what is left to do.
greg0ire
force-pushed
the
build-with-dbal-3
branch
from
e142ed3
to
6a267f5
Compare
|
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? |
|
To me, sounds exactly what the project needs. Until the build is green, each patch will be merged at the reviewer's discretion. |
I'm curious if it could be implemented in the DBAL to re-enable PHP 8.1 builds. |
I think it could 👍 |
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:
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 🙂