Add tests against multiple Node.js versions

[mtrezza]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

Parse Server CI currently only tests against Node 10.0.0 and 12.y.z (latest patch version).
This does not reflect the variety of Node versions in use in real word deployments.

Feature / Enhancement Description

Keep the Node versions for CI tests in sync with the Node versions in Long-Term-Support.

That means:

• Removing the CI tests for Node 10 in April (EOL date April 2021).

• Add tests for the following LTS versions:

  Version	EOL Date	Latest Patch Release
  Node 10	April 2021	10.23.2
  Node 12	April 2022	12.20.1
  Node 14	April 2023	14.15.4

• When a new patch version is released, update the CI test version as well.

In addition, the Readme should contain a Node compatibility table to show against which Node versions Parse Server is tested.

This is related to #7160 which adds tests against multiple MongoDB versions and automatically ensures that tests always run against the latest patch version. A similar mechanism should be implemented for Node and leverage the existing mechanism.

Example Use Case

(none)

Alternatives / Workarounds

(none)

3rd Party References

(none)

[cbaker6]

@mtrezza I definitely appreciate this and your multiple mongo version PR!

Last year I had a PR that tested multiple (2) versions of Postgres. We opted for only testing one at the time because travis had the limitation of running 5 tests at once. I believe Github Actions doesn't limit (or at least we are no where near it) the amount of linux tests. What do you think about adding multiple versions of postgres along with a table to the README similar to your mongo table? Depending on the discussion, I can start the PR if you want me to.

The postgres EOL is here: https://www.postgresql.org/support/versioning/

Currently, 9.6 is still receiving supported through the end of the year, though I don't believe we need to go back that far as we've been testing Postgres 11 since ~4.2 (earlier actually, but I didn't want to go back through the older PRs). My suggestion would be to test 11, 12, 13.

Let me know if you think this warrants a separate discussion. I wrote this here because I thought it was closely related to node and mongo versions

[mtrezza]

@cbaker6 Funny that you wrote that comment, I was thinking about asking you about this, you being one of the Postgres experts here. I think it would be great to add this for Postgres.

The challenge for me was to find a source that provides the current MongoDB versions. I'd start off researching this for Postgres.

[cbaker6]

The challenge for me was to find a source that provides the current MongoDB versions. I'd start off researching this for Postgres.

Not sure we need the version check for postgres since it uses a docker image for postgis directly. The values used in the image will always pull the latest page for the respective major version. The only exception is when a new Postgres major version comes out like Postgres 14, which will need to be added manually. Here are the tags to show what I mean: https://registry.hub.docker.com/r/postgis/postgis/tags?page=1&ordering=last_updated

[mtrezza]

I see, so you wanted to manually add more Postgres versions to the CI? That is surely an easy fix if the docker containers always contain the latests Postgres patch versions.

So if I understand correctly, this means use Postgis image 11 which always includes the current latest minor version, currently Postgres 11.1?

parse-server/.github/workflows/ci.yml

Line 116 in 7f47b04

image: postgis/postgis:11-3.0

[cbaker6]

I was referring to the PR I added for MongoDB which contains a CI Self-Check that automatically checks whether the CI tests with he latest MongoDB versions. As soon as MongoDB releases a new minor or patch version (which they do every few weeks), the CI test will fail and we're reminded to bump the MongoDB version in the CI.

Yes, also, with the way Postgis creates their tags, the latest minor will always be pulled just by just specifying, postgis/postgis:10-3.1, postgis/postgis:11-3.1, etc. So the postgis will be like your mongo one, except we don't need to check for patch releases, only major releases

[cbaker6]

I guess a similarity would be the postgis version, but postgis doesn't release a lot of patched versions

[mtrezza]

Do you think we can remove POSTGRES_MAJOR_VERSION from the CI file?

parse-server/.github/workflows/ci.yml

Line 128 in 7f47b04

POSTGRES_MAJOR_VERSION: 11

It seems to be used only for a log output?

parse-server/scripts/before_script_postgres.sh

Line 5 in 54a61b7

echo "[SCRIPT] Before Script :: Setup Parse DB for Postgres ${POSTGRES_MAJOR_VERSION}"

[cbaker6]

What is this POSTGRES_MAJOR_VERSION then for?

Do you think we can remove POSTGRES_MAJOR_VERSION from the CI file?

Good questions. This looks to be left over from the scripts I wrote for travis that are now used for Actions. It's only used in one place now to print the version number to the script. Previously, this was needed because the script needed to behave differently with different versions, but not anymore

So it can be removed

[mtrezza]

I realized your PR solves this by setting it as a var from the matrix. I was just worried about forgetting to update in two places, but we can leave it there then. -- Edit: as you wish :)

[parseplatformorg]

🎉 This change has been released in version 5.0.0-beta.1

[parseplatformorg]

🎉 This change has been released in version 5.0.0