IBX-5091: Bump Postgres CI to 14

[glye]

Question	Answer
JIRA issue	IBX-5091
Type	improvement
Target eZ Platform version	v2.5
BC breaks	no

Current CI runs on PostgreSQL 10, which is no longer supported. Current supported versions are 11 to 15. Version 11 is good until November. https://www.postgresql.org/support/versioning/

The Postgres CI tests pass, and the log shows 11 installed successfully, so this seems to be it unless we want to bump it even higher. Edit: Bumped to 14 on Adam's suggestion.

Maybe we should bump MySQL from 5.7 too?

Checklist:

• Provided PR description.
• Checked that target branch is set correctly (master for features, the oldest supported for bugs).
• Asked for a review (ping @ezsystems/engineering-team).

[adamwojs]

Could you please bump PostgreSQL version directly to 14?

[glye]

Bumped to 14.

[Steveb-p]

@adamwojs why are we updating the version to almost the newest version of the database, and in a codebase that is in maintenance mode?

In most projects database under test should be the one with lowest version number. This ensures that generated SQL commands will work in the version that has the least features. We shouldn't touch database versions in projects in maintenance mode, and test against the lowest acceptable version.

Whether or not it remains supported by vendor is irrelevant - it was at the time that this branch went into maintenance-only mode.

[gggeek]

Not that it is my business to meddle with Ibexa company policies, but re:

Whether or not it remains supported by vendor is irrelevant - it was at the time that this branch went into maintenance-only mode.

I think that a product being in active maintenance is not a frozen product - that is definition of something unsupported. Updating its CI testing against the oldest still supported stack of dependencies seems to make sense - after all end users are not supposed to run an OS, DB or Web server which are out of maintenance. Whether the "oldest actively supported postgresql version" is the one from upstream or the one from redhat/ubuntu/platformsh is another decision. But hey, CI can to help with cases such as these, as it is not too hard to test against 2 or even 3 versions of the database :-)

[glye]

Note related issue ibexa/documentation-developer#1958
If we really do recommend 14 or higher then running CI on 14 is good. If 11 is actually still considered perfectly legit then I'd go with 11.

We do indeed expect users to not run out maintenance dependencies, so I think 2.5 being EOM is not a good reason to leave it at 10+. (Also it looks like we're not paying attention.)

Postgres 10 might be well supported by distros still, of course. I'd like to add something like this to the general recommendation description above, ref the doc PR:
"Always use a version that receives security updates, either by the vendor themselves or by a trusted 3rd party like the distribution vendor."

[Steveb-p]

Not that it is my business to meddle with Ibexa company policies, but re:

Whether or not it remains supported by vendor is irrelevant - it was at the time that this branch went into maintenance-only mode.

I think that a product being in active maintenance is not a frozen product - that is definition of something unsupported. Updating its CI testing against the oldest still supported stack of dependencies seems to make sense - after all end users are not supposed to run an OS, DB or Web server which are out of maintenance. Whether the "oldest actively supported postgresql version" is the one from upstream or the one from redhat/ubuntu/platformsh is another decision. But hey, CI can to help with cases such as these, as it is not too hard to test against 2 or even 3 versions of the database :-)

What I mean by maintenance mode is that there are no new features being added to that particular version. Of course there are still bugfixes, CI is expected to pass, etc.

We could test against multiple database versions, and it is fairly easy to do. We're usually refraining from doing so because ANSI databases are rather safe'ish for upgrades, and value brought by these is not worth the additional cost for private repositories (we're usually removing intermediate PHP versions for this reason too). However, since this is public (and therefore free) it is perfectly acceptable for me to add it.

@glye can you take care of it, or do you need my help with config?

[Steveb-p]

We do indeed expect users to not run out maintenance dependencies, so I think 2.5 being EOM is not a good reason to leave it at 10+. (Also it looks like we're not paying attention.)

It's the same as PHP. Users are expected to upgrade, but many will not. And we're not dropping support for earlier PHP versions for this very reason.

[glye]

@Steveb-p Testing multiple ones is fine. We're testing 4 php versions here. Maybe assign postgres versions 10, 11, 14, 15 to them, so we don't increase the number of tests? It's free, but still it's nice to save time and not boil the planet, etc. :) I could use some help, thanks, I don't immediately see how to do it.

[Steveb-p]

@Steveb-p Testing multiple ones is fine. We're testing 4 php versions here. Maybe assign postgres versions 10, 11, 14, 15 to them, so we don't increase the number of tests? It's free, but still it's nice to save time and not boil the planet, etc. :) I could use some help, thanks, I don't immediately see how to do it.

Changed the test matrix to allow multiple versions of databases. Feel free to adjust as necessary.

Additionally, I've removed the deprecations that we're already there, and dropped intermediate PHP versions for integration tests specifically.

Test runs overview: https://github.com/ezsystems/ezpublish-kernel/actions/runs/4741986725

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information