Allow Symfony 6

[Kocal]

No description provided.

[nicolas-grekas]

We should wait a bit before allowing Symfony 6 because we're still breaking BC there (eg adding return types).

[greg0ire]

Converting to draft until the right moment.

[wouterj]

Fyi, all types have been added and work on this PR can resume :)

[derrabus]

Can you please rebase and resolve the conflicts?

[Kocal]

Done, however I think it won't works because I can't set Composer's minimum-stability anymore.

Should we wait for Symfony 6 official release to re-run this PR's checks?

[derrabus]

Done, however I think it won't works because I can't set Composer's minimum-stability anymore.

@greg0ire Can you have a look, please?

[greg0ire]

I've tried something, but it's getting late, and I have to think this through a bit more (the extra prefer-lowest job and upload coverage job seem wrong)

[greg0ire]

I removed my commit because I cannot find a satisfying solution. I think in this case, we should partially revert 739d439, or just maintain an MR open that sets the stability in composer.json to dev, and merge it (after dropping the commit that does this) once Symfony 6 comes out. Having a workflow that oscillates between a custom version and a generic one does not sound great.

[derrabus]

@greg0ire But adjusting the minimum stability for a CI job is not a very uncommon need. Wouldn't it be possible to add an optional parameter to the workflow that would result in a composer config minimum-stability $value being run before installing the dependencies? That's all we need here, I guess.

[greg0ire]

But adjusting the minimum stability for a CI job is not a very uncommon need. Wouldn't it be possible to add an optional parameter to the workflow that would result in a composer config minimum-stability $value being run before installing the dependencies? That's all we need here, I guess.

We would also need an extra job under include in the build matrix, and currently there does not seem to be a straightforward way to make it conditional (I'm assuming we don't want to do this for every Doctrine repository, can be challenged at the org level).

[derrabus]

We would also need an extra job under include in the build matrix, and currently there does not seem to be a straightforward way to make it conditional

I see.

Would it be possible to decouple the workflow from the matrix? My idea would be to have one parameterized phpunit workflow that runs the tests for a single given php-version and dependencies setting. The continuous-integration workflow run this new phpunit workflow with different parameters.

This way, we could add additional parameters to the phpunit workflow that the continuous-integration matrix does not make use of, like minimum-stablity. A project could use the continuous-integration workflow and add additional phpunit jobs with custom settings.

[derrabus]

Psalm's ReservedWord check is broken. It complains because Symfony has added mixed type declarations to parameters. I'll prepare a bug report for Psalm, but for now I've disabled it because it reports false positives.

[greg0ire]

Would it be possible to decouple the workflow from the matrix? My idea would be to have one parameterized phpunit workflow that runs the tests for a single given php-version and dependencies setting. The continuous-integration workflow run this new phpunit workflow with different parameters.

This way, we could add additional parameters to the phpunit workflow that the continuous-integration matrix does not make use of, like minimum-stablity. A project could use the continuous-integration workflow and add additional phpunit jobs with custom settings.

Yes, that would be possible and was in fact quite similar to what I did with my previous attempt. There are things left to get right though, like how to upload coverage. I'll give it another try.

[greg0ire]

My new attempt can be seen at #456